So…you’ve just been asked to take over project management responsibilities for an in-flight project.  (Wouldn’t it be nice to manage a project from day one for once?)  In the process of getting your arms around the project, you’ll be going through a litany of tasks.  Those tasks will likely include

  • confirming existence of and reading (signed) project charter
  • confirming existence of and reading (signed) business requirements document
  • reviewing functional design specifications (as appropriate)
  • reviewing technical design specifications (as appropriate)
  • perusing minutes of status update meetings
  • reading any change management governance logs

                       and, of course,

  • going over the project plan with a fine-tooth comb.

It is this last task that will consume most of your time.

Besides the usual queries—“Is it behind/ahead of schedule?  Is it over/under budget?”—we typically want to get a feel for whether or not we have enough resources assigned to the project to in fact deliver the remaining work effort on time and on budget.  MSP 2010 and 2013 give PMs a quick read concerning overallocated resources via the “red man” icon.  In previous versions (and for a deeper look in 2010/2013), you will probably want to view or print the Overallocated Resources report.  The Overallocated Resources report is going to show you the percentage that a resource is overallocated.  For resources with assignment units of 100% and an 8-hour workday, 125% would indicate 2 hours of overallocation—or a 10-hour day.

So, you review this report and see an overallocated resource.  When you look at the work assigned to the resource in the given timeframe, however, you find that he/she is not overallocated.  What is going on here?  This spurious reporting of overallocation is no fault of MS Project.  It has to do with the method the previous project manager used to track progress.

There are basically four methods of tracking progress that correspond to varying levels of detail needed.

  • Recording project work as scheduled
  • Recording each task’s completion percentage
  • Recording actuals—actual start, finish, work, etc.
  • Recording time-phased actuals.

The last method is, of course, the most detailed and provides the best insight into a project’s health.  For various reasons, though, it is often not utilized.  This could be due to the time/effort required, a lack of impetus from management, or a deficiency in understanding project management best practices in general or the PM tool in particular.

In our scenario—a PM being brought in to take over a project—the history might look something like this.  An existing resource on the project is asked to be the PM, too.  (“It can’t be that hard, can it?  After all, they are a senior-level programmer.”)  The “PM” does their best, but soon they, the management, and the stakeholders realize the project is “in the weeds.”  The decision is made to bring in a project manager.  Our project manager checks the health of the project and finds “overallocated” resource(s).

He/she realizes that the previous “PM” likely tracked progress using the “as scheduled” method.  That’s fine—if that is what really happened (miracles do happen)—but most likely it did not.  Here’s an example.  Task 1, scheduled for 5 days, may have only taken 4.  The resource then began immediately working on the next assigned task.  When task 1 was reported 100% complete as scheduled, MS Project believed that it really did complete as scheduled.  When task 2, then, was reported to have started a day early (which it did), day 5 shows the resource overallocated 200%—the 8 hours from task 1 (MSP was told it completed as scheduled) and the 8 hours from task 2 (the resource really did start task 2 ahead of schedule).

This is a simple example for sake of clarity.  But, one could easily see that if tasks were done out of chronological sequence—and progress was reported as scheduled—a task out in the future would be marked complete and the resource marked overallocated based on the other tasks assigned to them at that same time.  (In SDLC projects this might very well happen as programmers work on separate modules having no true finish-to-start dependencies—if the PM does not reorder the tasks.)

As you can see, the problem is one of the project tool showing future work as being already complete.

The solution is not necessarily easy or fun.  Do your best to determine when the task was actually worked and capture that information in the project tool.  It should always be in the past.  Once all of these spurious “overallocations” are resolved, then any future overallocations that show up in the report are truly that and should be dealt with accordingly.

Like this post? Share it!