Real-Life MS Project: Take Back Control by Alex S. Brown, PMP

Microsoft Project is a widely-used scheduling tool. Its quirks and complications are a huge drain of time on the Project Management community. This series will go beyond tips and tricks to discuss solutions to real-life problems, to achieve real time-savings for its many users.

MS Project default settings can work against the experienced project manager. A common complaint about the tool is, "I hate to touch anything once I have my schedule right. If I change anything the whole schedule seems to fall apart." With four simple steps, any project manager can take back control. The Project Manager needs to run the schedule, but all too often MS Project can try to take control. Take back control by understanding the tool better.

Scheduling Options in MS Project

#1 Automatic Predecessors and Successors

Some MS Project default settings only make sense if you want to demonstrate the tool. If you want to quickly generate a phony schedule with the minimum of keystrokes, it makes sense for each task to be the predecessor of the one before it. Task #1 depends upon task #2, depends upon #3, and so on. By default, MS Project will create these dependencies for you. Unless you always work on single-person projects, and you always execute your entire task list from top to bottom, you should consider turning off this "feature". Whenever I get a new computer, I always launch Project and change this setting. When I create my task list or WBS, I want to focus on breaking down the work, not on dependencies. When adding dependencies, I want to decide what they are and create them myself.

To change this setting, go under the Tools menu, to the Options menu item. Go to the Schedule tab, and clear the "autolink inserted or moved tasks" checkbox. You may turn this feature on temporarily, to enter a string of dependent tasks, but most project managers should keep this checkbox cleared most of the time.

#2 "Fixing" Your Tasks

Every MS Project user I know has told me the same story: it is an hour before the project status meeting. The schedule has changed in some dimension: estimated work-hours for a task, duration of a sign-off, or another task-level date. This change will ripple through the schedule because of the dependencies. For some reason, though, MS Project will not change the date to what it must be. The change is obvious and simple, but every time you enter the new date, the program either replaces it with the old value or adjusts something that should not change.

Ninety percent of the time, the problem lies with the task type: fixed work, fixed duration, or fixed units. The difference between these three will explain why many values jump when you make just one adjustment.

MS Project has a basic calculation for all tasks: duration times units equals work. In plain English, a task that will take eight hours to complete (duration), has a full time resource assigned (100% units) requires eight work-hours to complete (work). A task that will take 40 hours in duration, that takes only 10% of a person's time, only requires 4 work hours.

This basic equation is clear, but once you start making changes, it takes on a life of its own. If you change the work-hour estimate for the 8-hour duration task to 16 hours from four hours, what should happen? Does that task now take 16 hours duration, or two people (200% units)? MS Project decides what do to after checking which value is "fixed" for the task.

If the task is fixed duration, then any change to either work-hours or units will affect the other, without changing duration. For the 40-hour duration task, increasing the work estimate to 8 hours will increase the units to 20%. MS Project assigns the task to spend more time per day, to get the job done in the same duration.

If the task is fixed units, any change to duration or work-hours will affect the other. For the 40-hour task, increasing the work to eight-hours will increase the duration to 80-hours, while keeping units at 10%. MS Project assigns more time to the task, keeping the units fixed.

If you change the fixed value, MS Project behaves as follows:

• Change the duration of a fixed-duration task, and the work changes (units stay the same)
• Change the units of a fixed-unit task, and the duration changes (work stays the same)
• Change the work of a fixed-work task, and the duration changes (units stay the same)

The first rule of working with units, duration, and work is: figure out your goal BEFORE changing values. Just because MS Project might keep the duration constant when the work doubles or it may double the duration; as the project manager you need to know what should happen. MS Project can print reports for you and track the effect of your dependencies, but it will never predict your project work for you. Choosing the right setting for each task will make the process easier for you.

Fixed units are great for tasks that always consume the same amount of work-time every week, no matter what. Earned value books call these tasks "level of effort" and they include supervision, management, and status reporting tasks. The more time they are performed, the more work-hours they consume.

Fixed duration is my favorite task for IT projects. If you use the saying, "it does not matter how many women are pregnant, it still takes nine months to make a baby," then enter "fixed duration" into MS Project. No matter how many resources or work hours are assigned, the task will always take the same duration of time. Fixed duration is also great when you want CONTROL over the duration of your tasks. I often find, for instance, that adding people to a task may reduce its duration, but not quickly and not easily. I use fixed duration tasks so that I can increase the resources on a task and then manually change the duration. I want to make a decision before changing a duration, and MS Project lets me do so if I choose "fixed duration". Fix the duration and enter the work effort, and MS Project will figure out the units. Perform resource leveling and MS Project is solidly under control.

Fixed work is useful for tasks that scale up or down perfectly along with the resources assigned. Production tasks sometimes work this way, if you have an efficient production process. So long as you have enough machinery, for example, adding more machine operators will increase manufacturing production nearly linearly. Double the resources, and you halve the time needed to produce a given amount. When using this method, be careful. It will never factor in learning effects, communication overhead of a large group, the cost of splitting a task, nor the cost of dragging out a task over time. You need to remember that MS Project will adjust your schedule automatically, and remember to add tasks or work-hours to cover these effects. At a certain number of resources, for instance, you may want to add a fixed-units "management" task, covering the same days as the fixed-work production task. The manager will oversee production and help with communication. Alternatively, just adjust each person's work estimate when changing assignments, taking into account the added overhead of large-group efforts.

#3 Control Your Resources' "Efforts"

The next complaint of new MS Project users is random changes when adding or removing resources from a task. "Effort driven" tasks can make your work and units change on a task every time you add a new resource or take one away.

The theory of effort-driven tasks is that if someone is already assigned to a task and another person is added, the two people should split the work. MS Project will automatically divide up the work, possibly changing the duration or units, depending upon what is "fixed" for the task (see #2 above).

It sounds like a good idea, but the results are hard to predict. My advice is to turn off "effort-driven" settings for MS Project and to enter the names, work-hours, and percentage allocations for each and every resource that you assign. When you add a second resource to a task, give resource #2 some of the work-hours and reduce the work-hours for resource #1. Keep control over the tool.

If all your tasks always cut in their duration by one-half when you go from one resource to two, then you will probably like the default effort-driven behavior. No IT project manager that I know has that kind of efficiency, though, so I recommend changing work amounts by hand for each resource assigned. Changing resources assigned always changes the work-hours needed, in my experience.

To change the settings for both effort-driven and task type (fixed duration, units, or work), go to the Task Information dialog box, in the Advanced tab. These settings appear many places in the program. All of the split-screen displays for the Gantt chart show these values and let you update them.

If you have an existing plan you may want to make a project-wide change to these settings. Select all your tasks by clicking on the gray square in the upper right corner of the Gantt chart table view (where the task numbers and the column headings come together). Click on the Project menu, Task Information. Under the Advanced tab set the task type and effort-driven flags to your preferred value, and click OK.

Change the default settings for all new tasks under the Tools…Options dialog box. Go to the Schedule tab and enter a new value for default task type and check or clear the checkbox labeled "new tasks are effort driven". My recommendation is fixed-duration, not effort driven, for maximum control.

#4 Changing Start and Finish Dates Looks Easy, But…

MS Project puts start and finish dates on the default Gantt view, and it is easy to go in and overtype the values. The results might disappoint you.

Typing a value into those fields may help to adjust your schedule, but in the background, it creates a "constraint". Entering a start date creates a constraint that the task will "start no earlier than" the date entered. Dependencies can force a later start date, but if the schedule changes, the task will never move before the date entered.

Entering a finish date creates a constraint that the task will "finish no later than" the date entered. Dependencies can allow an earlier finish date, but if other tasks are late, the finish date for this task will never go any later than the date entered.

These constraints can foil attempts to improve the schedule, or hide the fact that your final end-date is in jeopardy. Constraint dates are useful for specifying truly fixed dates, like quarter- or month-ends, but you need to understand what they are doing to your schedule. The indicator column in the Gantt chart (between task name and task number in the default view) will show a calendar icon for tasks with constraint dates. In a future column on resource leveling, I will review the use of "delays" to completely eliminate these calendar icons from your project plans, except for truly fixed dates.

To view or change the constraint dates for a task, go to the Advanced tab on the Task Information dialog box. "As soon as possible" is the default setting for a traditional, left-to-right, project plan.

If you change both the finish date and the start date, MS Project not only adds a date constraint but also changes the task duration. To compensate, the tool must then change the units for each resource, keeping the work constant. These changes can create chaos in a well-tuned plan. Rather than typing in dates, adjust the resources, predecessors, successors, units, work, and duration for each task to suit the project goals and constraints. Let the dates be a byproduct of those decisions.