I have been supporting Microsoft Project for over four years and there is one problem I see repeatedly as new project managers start using MS Project: They become so involved in creating the “perfect” plan that they resist the “corruption” of reality.

Microsoft Project can do a lot of things. But no matter how long you tinker with it, it will not solve management issues like a shortage of staff or other real-world complications. Solving those problems remains the domain of the project manager.

I’m continually amazed by project managers who often miss this seemingly obvious point. They become so engaged in the process of creating a plan that they neglect the realities of the situation. Microsoft Project is a powerful, but sometimes misunderstood, tool. Here is an example:

A common mistake
A project manager builds his plan using Microsoft Project 2000, covering the details by outlining tasks and assigning resources. MS Project will take these assignments and figure out how much work is scheduled per day. Many project managers pay close attention to these distributions because they are key metrics affecting deadlines and completion date.

In this example, we’ll focus on one task. The project is set to start on April 2 and end on April 6 and will require 40 hours of work to complete. This task has one resource (remember, staff members are termed resources in Project) assigned to work the entire 40 hours of work (eight-hours-per-day across the five-day duration to equal the 40-hour task).

The project manager decides that the work value is key to him, so he sets the task to be a Fixed Work task type. But by the second day of the project, our project manager is already in trouble.

The first eight-hour day goes just as planned. But he works only six hours on the second day. This shortfall means that two hours must be put at the end of the task timeline, pushing the new finish date to April 9.

As time goes on, and the resource works less than eight hours per day, the finish date keeps going and going. Our poor project manager’s hair is now turning gray because his plan is no longer perfect.

Often these project managers then spend a great deal of time trying to figure out what Project did to ‘break’ his plan, when in reality, Project was on target.

MS Project was correct because, according to the settings it has for hours per day and the settings that designate working days, the changes it made to the task are valid.

Why is this a common problem? There are several reasons. First, many users do not have a firm grasp of what it is that Project does when it recalculates dates or other data. They just see some things values change and they feel like it is somewhere in the realm of black magic.

Second, many people managing projects are unclear on the finer points of project management. They are looking too closely at some data and not closely enough at other data. They are staring at the dates and missing the greater question of why work is being completed slower rather than scheduled by MS Project.

A better approach
Project cannot predict the future. It does not claim to tell you what will happen but rather what might happen, given the information you have supplied. It will look at the trends and the data and give you notice of what will happen if no further action is taken.

Our project manager was telling Project that the work was being done slower than projected so the software, in turn, showed that this slowed work pattern would cause the task to finish late.

This manager was missing the real point: The task will be late unless he does something. What he saw was data changing without making the connection between the data and the reality of the resources working on tasks.

An experienced project manager would have looked at the situation above and made the connection that the original estimates were off and action needed to be taken. What our project manager should have done was examine why the work was going slower and determine how he could change the situation, not the numbers. The focus of this project manager should not be on troubleshooting the Project 2000 scheduling engine, but rather on how to fix the very real staffing issues and resource efficiencies of the project.

Project managers need to be thinking about the following:

  1. Can this resource work overtime to get the project back on track?
  2. Would adding another resource help meet the original finish date?
  3. Can we reschedule this work so that finishing it later than scheduled will not affect other tasks?

The key concept for our project manager to remember is that just because the plan says the task will finish later than first thought does not mean that the apocalypse is upon us. It just means that something might need to be done to get this task back on track.

And the moral of the story is
The point to come away with here is that your plans will not always be on target. Many people may theoretically accept this, but what matters is how you react to these changes.

The goal of the project manager is not to build a plan that does not change but to be able to deal with the changes that will occur no matter how thoroughly you plan.

Good project managers do not fear changes. A good project manager watches the data, uses the software to help identify trends, and then deals with the changes before they become problems. The art lies in your ability to monitor progress, predict potential issues, and deal effectively with those issues that cannot be avoided.

Use Project as a tool to monitor potential trouble and remember that the plan is not reality; the resources doing the work are reality.

Share your project management war stories

We’d like to hear your project management war stories. What mistakes have you seen or what mistakes have you made that helped you become a better project manager? Post your comments below.

Brian Kennemer is one of the only six Microsoft Most Valued Professionals for Project, volunteering his time in the Microsoft Support Newsgroups to help users with their everyday questions and issues on Project.