With all the “Top 10 Lists” out there on varying subjects, I thought it was time to create one for Microsoft Project. Most beginners that are given Project are simply thrown a copy of the program and maybe an 800 page book that reads like assembly instructions for a Space Shuttle.
In the real-world work place classes are just not an option, usually due to budget constraints. With the proper training and a good understanding of a few simple rules, the users frustration level can be drastically reduced to a tolerable level. So, here is my list of a few basic rules or guidelines to consider when working in Project.
- Project is not Excel.
This may seem obvious but surprisingly when you first open a new project, most are inclined to think in terms of an excel spreadsheet. After all, it’s been ingrained in our thought process since the dawn of Microsoft Office. While the grid-like layout of the “Gantt Chart” may look similar to excel, make no mistake, it is different. It may look similar but it behaves very differently. For example, Project will automatically change the start and end date. Let it. Remember, this is a scheduling tool and scheduling tools change dates based on other inputs. Not understanding how and why it does this will lead most newbies to abandon the software. Stick with it and it will become a valuable tool.
- Understand the basic scheduling formula.
(Duration = Work divided by Units)
This is a fundamental formula across all scheduling practices and thus is no different in Project. Understanding this formula and the definitions of the words themselves is vital in comprehending how Project schedules and manipulates tasks. Without an understanding of this formula, changes made by Project may seem obscure and unjustified. Knowing the formula may not stop Project from making changes to your scheduling, but it will help you better understand what changes to expect given certain modifications on your part.
- Setting fixed types.
By default, Project will set the “units” as fixed, when in reality most often we would want the “work” as fixed. On a default set-up where either work, units or duration is fixed and you modify one of them, Project will recalculate the third but will not change the one that is fixed. Since most technical tasks are driven by the amount of work effort required, they should be set so the work type is fixed. You would set the work type as fixed if you do not want overtime. So, if your order for units increases you can plug in the new quantity and since the work is fixed, Project will adjust the time and provide you with a new deadline for production. In the same respect you can change the fixed type to any of the three options so if your deadline gets pulled in, adjust the new duration while keeping the same quantity of units and Project will calculate the adjusted amount of “work” or hours needed.
- Don’t assign everyone at 100%.
When you assign a resource or person to a task, the default in Project is 100%. This means that that resource or person will work solely on that assignment. In some situations this is okay, but it limits that resource to only that task for the duration of the task. This will result in erroneous numbers and timelines in Project. Also pay attention to assigning people or resources to concurrent (parallel) tasks. Although most of us like to think we can multi-task, in Project it just doesn’t work.
- Minimize those constraints.
When you add constraints such as “Start no earlier than” or “Finish no later than”, you are actually telling Project not to schedule anything. While there may be legitimate uses for such constraints, such as a dependency on an external event, the best practice is to let Project adjust the schedule. This is known as Dynamic Scheduling. Difficult or inflexible constraints may cause scheduling conflicts and force Project to ignore or eliminate a particular project schedule. If your sponsor (by sponsor I mean boss) mandates an end date then use Deadlines. Deadlines will flag a missed milestone but will not disable scheduling of the task.
- Avoid estimating or guessing the Percent Complete.
Estimating the percent complete for a project is a practice you should avoid. This often becomes a habit and soon becomes a subject of abuse. The best practice should be to ask a resource (or manager) to report the actual work then calculate the remaining work. This will allow project to automatically (and correctly) calculate the percent of work completed. A point to remember is that; in project the percent complete actually means duration complete which is distinguished from work complete. Remember, we are using Project – not Excel. Before you make changes to work or units, make sure you understand the difference between work complete and duration complete.
- Let your project program talk to you, and listen to what it says.
Think twice before you hit the “ignore” button when Project pops up an error message “This action will cause a scheduling conflict…” They are there to warn you of potential problems that may occur if you continue. Deal with the errors or conflicts immediately or their consequences will have long term effects. Not taking care of them now will make it more difficult to trace back later when these issues start stacking up.
- Leveling is not a magic wand.
As anyone who has used automatic leveling can tell you, there is no real magic to it. Leveling simply delays the start or continuation of a task or tasks in a schedule until your resources are no longer over allocated. It’s best to use some thought when first assigning resources to tasks. A common mistake is to assign a person full time to more than one task that is on the same scheduled time frame. If you are careful, leveling can work great for you, if not it can be a nightmare.
- Tools are not communicators.
Considering the various collaboration tools in the Enterprise Edition of Project Management (EPM) environment including things like notifications and SharePoint, you may be inclined to think the tool can communicate for you. Wrong! Ninety percent of a project manager’s job is communication. PM tools may facilitate some communication and relieve us of some mundane tasks allowing us to spend more time communicating – but it will not replace it.
- Knowing project management will not make you a project manager.
Project Management Institute (PMI) identifies 44 processes that a typical project manager performs. Project really only handles a few of these processes. Project makes a good manager better and a bad manager worse. Project will facilitate some of your routine scheduling tasks so that you can devote the bulk of your time to truly managing your projects.
Also visit my new “About me” blog at https://www.aubreywlove.com
Pail Writer 