This blog post is one in a series of 10 based on a presentation I developed, “Top 10 problems new (and not so new) Project users have, and what you can do to ease the pain.” I first gave this talk at a Puget Sound PMI chapter meeting. I later gave an updated version of the talk to my local chapter of the MPUG Project User Group. As you might expect, at the PMI meeting the discussion tended more towards the broader project management issues, while at the MPUG meeting more towards specific features in Project. In fact at the MPUG meeting I had my computer projecting and we played around with Project features that related to some of the issues I brought up.
Top Ten List
In the process of writing the Project Step by Step books (starting with the 2000 edition and continuing through the current edition) with my co-author Tim Johnson, I observed first-hand some of the problems Project users encounter. Some of these problems are straight-forward gotchas in the software, but many common problems were really about how people define, understand and practice project management. In this and the other posts in this series, I’ll guide you through each of the top ten problems new or inexperienced project managers encounter, and what you can do to help identify and address these problems.
Problem #4: Track by percent complete
Project managers who track progress by percent complete often mistake elapsed duration with progress, such that when they're 75% out of time they think they're 75% done. Sadly, this is often not the case.
Planning is dandy but...
This isn't an exclusive list, but in general I see two types of Project users, which I'll call "planners" and "trackers." Planners use Project to create their initial project plan, most typically resulting in a Gantt Chart that they then print or share online. Once work starts, however, planners' use of Project ends. They don't track progress in Project in any fashion.
Trackers, as the name suggests, are planners initially who, once work starts, record progress in Project. These Project users are really getting their money's worth from Project, for tracking progress engages the scheduling engine at the heart of Project, and distinguishes it from simpler drawing tools. Microsoft Visio, for example, has some nice Gantt Chart drawing capabilities and is in my opinion a simpler way for most people to produce a basic Gantt Chart. But zealots like us want to do more, of course, like track progress.
Precision is not accuracy
The activity of tracking progress boils down to this: is work in the plan proceeding as planned, or have we encountered some variance? Or I might be more focused on cost: is the work going on in the project costing what I expected, and am I getting my money's worth for the results of the work? Tracking progress is one of the key activities that elevates one from a planner to a project manager.
Project supports various ways of recording progress. From simplest to most complex, these include:
- Work completed as scheduled
- Percent complete
- Actual start or finish; actual and remaining duration
- Timephased actual work per time period
We covered all of these tracking methods in the Project Step by Step books (see references below), so here I'm going to focus just on percent complete. This is the tracking method that I think is most risky: it offers the veneer of precision but can lead to significant problems in accurately knowing the state of work or completeness in a project plan. One of my project management mentors once cautioned me not to confuse precision with accuracy: data can appear extremely precise yet be completely wrong. Tracking progress by percent complete, with the wrong intent, is one such example.
The parable of the term paper
Let me describe the risk of tracking by percent complete through this parable.
Johnny is a typical college student enrolled at the state college. Johnny enrolled in a course that has a duration of 10 weeks. This course requires only a single assignment: a term paper to be turned in at the last class session. Johnny's entire grade for this course will be based on this paper.
Johnny is young, so 10 weeks seems like practically an eternity to him. Two weeks go by and Butch, Johnny's older and wiser brother, asks Johnny how the paper is progressing. Johnny responds "I'm off to a good start, in fact I'm right on track." The truth is Johnny hasn't started any work on the paper. After all, he has eight weeks remaining and that's practically an eternity.
More time passes. In the sixth week of the course Butch again enquires about the state of the paper. This time, with some forced enthusiasm, Johnny replies "Oh, I'm on it!" By this Johnny means he hasn't yet started any work on the paper, but he is now giving some serious thought to getting started real soon now. After all, he has four weeks remaining and while not practically an eternity, it's still a long time.
On the last night before the last session of the class, Butch arrives at Johnny's dorm room with triple-shot cappuccinos in hand because, as Butch has suspected all along (he is after all wise) Johnny is staring into the terror of his last night in which to start and complete what was intended to be a 10-week project.
What Butch knew that Johnny did not was this: do not mistake elapsed duration with percent complete. After the second week of the course, when 20% of the 10-week duration had elapsed, Johnny oh so wanted to correspondingly be 20% complete, but he was in fact 0% complete and now 20% out of time. Likewise after the sixth week Johnny remained 0% complete but now dangerously low on remaining duration. Johnny had in fact passed the point of recovery. The project is now a salvage operation at best, not an opportunity for academic achievement. Butch, being wise, had decided that Johnny would learn a more valuable lesson by failing at the project than he would learn by executing it competently.
Johnny's not alone
I see the same type of mistake made in teams of knowledge workers. I've seen work items in software engineering schedules, for example, tracked with percent complete in line with elapsed duration pretty predictably right up to 80% or 90% complete, but then the work item gets stuck in almost-done limbo, and stays in that state well past its target completion date. In fact, it might stay at 80% complete for 50% of its actual duration. It becomes the work items that blows up the project's schedule. It may also distract attention from other similar but slightly less severe schedule problems with other work items.
One challenge with tracking progress with percent complete is that while we might have a clear definition of what 100% complete for a given task looks like (and for knowledge work even this can be a big if), we might have no clear and shared understanding of what the intermediate states of completeness should look like. Lacking any previously defined and commonly understood incremental levels of completion, I am free to declare just about any percentage of completeness that I wish right up to the 100% threshold. For complex work, this is highly risky project management.
Checklist management
Yet for some projects I manage, I do track percent complete. But I do so with a very simple goal. I want to use the task list as basically a sequenced to-do list. I use these percent complete increments (which are handily exposed on the Tracking toolbar in Project):
- 0% = work on task is not yet started
- 50% = work on task started
- 100% = task is complete
I use this approach when I don't need more detail in the project plan. The nature of a task might not allow for incremental points of completeness, or I may have some other means of tracking progress outside of Project. For example right now I have a task in a project plan that is really an umbrella task that describes work required to resolve a large number of issues in an issue-tracking database. For my purposes I need to convey that this work is underway so I mark the task as 50% complete, but my more detailed progress tracking goes on in the issue tracking database. This approach works so long as I and my stakeholders who see the project plan understand that is my intent.
Are we done yet?
I have found that when a project manager and the resources who will perform the work have a discussion about what incremental and final completeness should look like for the tasks in the project plan, goodness results. If you can come to clear, verifiable definitions of incremental completeness, then tracking by percent complete may be perfectly fine. For knowledge worker tasks, however, keep in mind that completed work and elapsed duration often will not track together. Knowledge work is often front-loaded or back-loaded, or the nature of the task may be such that its real scope can't even be fully defined until one is well into the work (an example of what's called a wicked problem). Project has a variety of tracking tools but how you should track progress in your projects relies on your good judgment as a project manager.
Hands-on with Project Step by Step
To read more about this blog entry's subjects in the two most recent editions of Tim Johnson's and my Project Step by Step books, see the following cross-references.
Simple tracking
- Project 2007 Step by Step: "Tracking Progress on Tasks," pg. 120.
- Project 2003 Step by Step: "Tracking Progress on Tasks," pg. 106.
Advanced tracking
- Project 2007 Step by Step: "Tracking Progress on Tasks and Assignments," pg. 284.
- Project 2003 Step by Step: "Tracking Progress on Tasks and Assignments," pg. 276.
###
Aritlces like this just make me want to visit your website even more.
Posted by: Maralynn | 12/06/2011 at 12:51 AM