Monitoring Project Progress

Too often failing projects surprise us.    Have you ever had a project that seemed to be going along just fine, and then, when the delivery deadline drew near, suddenly, everyone’s two months late?  It leads you to wonder, “How could I have missed that this project was two months late?”  ”What planet was I on where this project appeared to be on time?”

Given that approximately three quarters of all technical projects fail to meet their schedule, budget or feature set goals, you’d think we would be better at spotting groups that are “off the rails.”  The reality is that determining when a project is in trouble is not an easy thing and problems that seem obvious in hindsight are murky at the time that they occur.

Monitoring project progress is an important part of a leader’s role.  Knowing when and how to intervene in failing projects is critical to the overall health of any technology organization.  Whether the intervention is to cancel a hopeless effort, or to correct team skill or resource imbalances, managers need to spot difficulties early in order to prevent issues from becoming disasters.

Of course, projects don’t really slip two months in one day.  They fall behind a little every day and the slippage accumulates until we notice it.  So the question is how can you notice the problems and fix them when they’re mole hills rather than mountains?

Most project methodologies call for monitoring task progress, budget tracking, and hours observations to check on the health of a project.  Unfortunately, I find that these are inadequate to gauge real progress.  Estimating task completion is notoriously subjective.  The last 10% always seems to take 80% of the time.  Counting hours expended has nothing to do with real progress.  Effort rarely equals results.  Although knowing how much of your budget has been spent is important, any positive correlation between the percentage of budget expended and percentage of project completed is generally coincidental.

The best method that I’ve found is to use what I call micro-deliverables.  Most projects are planned with series of tasks that lead to major deliverables, the documents, deployments, or code that the tasks create.  But these deliverables are usually the result of many people’s work over a period of weeks or even months.

Micro-deliverables are much smaller, individual efforts.  When you plan for micro-deliverables, each person on a project has responsibility for some physical product every few days.  Then you can gauge the health of the project by checking whether the micro-deliverables are done or not.  You don’t have to wait for months until a big deadline looms to check the health of a project.

When planning for and using micro-deliverables, there are a few simple rules to follow:

1. Never let anyone go longer than a week without owing a micro-deliverable.

Any time a person goes longer than a week without a deliverable, they go into a black hole of unknown progress.  You can’t really gauge how they are doing, and you are more likely to be surprised.

2. Micro-deliverables are either done or not done.

When measuring progress, there are only two states for micro-deliverables.  They are either 100% complete, or the 0% complete.  Progress is marked only by final approval of the item.  Otherwise, you get into the subjective world of guessing how close to done things are, which is inevitably inaccurate.

3. Progress is not measured in effort, but in micro-deliverables

The only meaningful measure of progress is whether micro-deliverables are done on time or not.  If they are coming in late, the project is late.  If they’re on time, the project’s on time.

4. A micro-deliverable is the responsibility of only one person.

If the deliverable is owned by more than one person, it becomes a problem to figure out where the real difficulties lie.

Using these simple rules, you can begin to identify project problems quickly and accurately avoiding the surprises that are otherwise all too common.