The problem with percent-complete

Does this sound familiar? 
PM: “Jason, what is the status of the XYZ Modulator?  Last week you were at 55% and management is breathing down my neck.”
Jason: “Well, I implemented the auto-reload, and the changes from QA. I’d say were about 70-75% done.”
PM: “Great 20% more than last week!  That will make the Powers that Be happy.”
… One week later …
PM: “Jason I need an update on the project status.”
Jason: “Uhhh, yeah about that. Well I found that the auto-reload didn’t work for have the new data types so I spend the last week fixing that.”
PM: “Oh.  Well what should I put as the percent complete? It’s 75% now.”
Jason: “Ummm, how about 80%...???”

When I witness these conversations, or hear about them, I see red flags everywhere.  Percent complete seems to have taken a life of its own outside a Gantt chart.  It has become, in some instances, the measure of all work.  Don’t get me wrong. I think it’s valid to say that we are X% to implementing a piece of functionality provided you also include a reference to a percent complete of what you’re measuring.  (I.E “We initially thought this was going to take 30 hours. That’s still valid and were about 50% there.” From this, one can deduce that about 15 hours have been worked on the code, and about 15 hours remain.) 

One problem with the initial, and far too common, example above lies in not having an underlying measure to use as reference.  If you don’t have some reference included the use of percent complete gets clouded.  Even trying to say ‘I’ve been working on the code for the last three days and I’m 60% through’ leaves some information out of the status.  Were you spending all of your time for the last three days on the code, or were you working on other tasks as well?  What are the plans moving forward?  Are you saying that you anticipate being done in two more days?  In 16 hours?    You’re 60% of what?

Another problem is using percent complete as the only measure of progress in a project.  By updating percent complete as the only means of a project metric, a project can appear to be progressing all the time at a steady pace when its not. The risk is that a culture can develop that the developers are conditioned to give some number greater than the last number they gave for percent complete.  Unfortunately for the developer, the number can’t go above 100%.  So what usually happens is a feature is started and the developer spends say two days working on the feature and feels that they are making good progress and say at the first status meeting that they are 30% (or some other optimistic number) complete.  The next two days they find that they didn’t account for a needed architecture originally in the first two days, so they spend the time implementing it. In the larger picture, in terms of having the feature implemented, they are at the same place as the last status meeting, but have a better architecture.  Since the metric is percent complete, not updating the metric would indicate that they didn’t do anything for the last two days.  So they have to give a number to justify their efforts.  So they choose a number like 15% and report that they are now 45% complete.  You get the picture.  Before too long the status chart shows the code at 80% complete, and in terms of hours spent to date over the overall amount of hours forecast, the number is much less than 80%.  Usually the percent complete starts to increase much more slowly; in increments of 1-5%, until the measurement is finally reset.  Eventually the reporting becomes a dance that everyone feels they have to perform, but nobody on the team has any faith in it. Unfortunately the memo to the executives is seldom sent…

It doesn’t always work out this way, but often I find that projects that rely on percent complete do so because management likes it.  It’s an easy thing for management to understand.   In addition the management in question often hangs their hat on the number and holds it to assumed (and often not-discussed) standards. 
Some of these standards include:
- If you’ve spent time working on the project and the percent complete didn’t increase, you didn’t provide any value to the project. (As described in refactoring example above.)
- Percent complete shouldn’t go backward.  If a house if 50% complete this week, it won’t be 40% complete next week unless some outside factors are in play (like a wind storm.)  Software development doesn’t work like this.
- Percent complete will increase at the same rate during the entire project.  Reporting that the project is 20% complete after two weeks often times allows people to assume that the project will be done in eight more weeks. 
- Percent complete is perceived to always be accurate.  If you say that you are 86% complete, it is assumed that there are empirical calculations to back that up.  Often times, the only thing to back the number up is the number a developer pulled out of the air during a meeting.  Even worse each developer throws out the number for the things they have been working on, so there isn’t any consistency between the metrics for the different tasks the team is working on.

This is why Visionpace follows the model of forecasting pieces of work in ‘story points’ and then when we start working on a specific feature, we break the feature into tasks.  The tasks are estimated in hours, and ideally the entire team is involved in determining the estimates.  This allows for multiple viewpoints and voices, and tends to create more realistic estimates.  As the tasks are worked on the status meeting focuses on:
- What did you work on yesterday (how many hours did you get to spend working on the task)?
- What are you going to work on today (how many hours are left on the task at hand)?
- What are the roadblocks, if any? By asking these questions regularly, the entire team is involved on all of the development.  Tasks that are underestimated initially are identified quickly and the factors that led to the underestimation are presented to the entire team, so they can be understood for the next estimating session.  Additionally, with this approach, if a developer is struggling with a task, it is apparent to the entire team and assistance can be addressed sooner rather than later.   One final benefit of measuring the tasks in hours, is that it’s easier to plan on when the tasks is expected to be implemented.  (Consider the statement, ‘I think there are six hours remaining on this task. I’m out half a day tomorrow for my kid’s doctor appointment, so I expect to have it done before lunch the day after tomorrow.’  This explains in succinct detail, what is going with the task.

If you’re interested in this approach feel free to contact me at Visionpace. We deliver custom software development following agile principles in Kansas City.