Percent Complete – The Seven-percent Solution

He raised his eyes languidly from the old black-letter volume which he had opened. "It is cocaine," he said, -- "a seven-percent solution. Would you care to try it?"

- Sherlock Holmes, in "The Sign of the Four"

In my previous post I extolled the virtues of ETC for estimating remaining work on a task.  But percent complete is so much more frequently used, it must have some virtues.  So, yes, it has the virtue of being easy.  Easy to calculate or easy to get a task owner to report.  So easy that it is addictive.  Yet the accuracy is so bad as to make it worthless.  Further it reinforces the wrong behavior on the task owner.

Most popular project management tools will calculate percent complete for you.  Depending on the task type, the tool can calculate percent complete on duration or work.  These calculations offer no predictive value, so they offer nothing to the PM as an early warning indicator.

Another way to get percent complete is very effective for tangible work.  Percent complete originated in the construction industry and it’s pretty easy for the foreman to walk around and see how complete a job is just from looking at the framing, siding or flooring.  So percent complete might also work acceptably with testing, if you carefully track total number of test cases and number of test cases executed.  But this doesn’t work for most software development tasks.

Alternately, the PM can ask the task owner how far along they are.  But the software development literature is littered with examples of problems from this.  I’ll describe a few.  First is that it is subjective:  unlike ETC, there is no way to validate the estimate or know on what it is based.  The PM is entirely dependent on the good faith of the task owner to get a meaningful estimate.

Second, it can progress to successively larger numbers without converging.  Three weeks into a four week task, the owner might report being 80% complete.  Since it is ahead, this is good.  The next week, though, the report is 90%.  Now the task is behind.  At the end of the fifth week you are told it is 95% complete and the next week that it is 98% complete.  What you really want to know, though, is “When is it going to be done?”  And you really wanted to know that around the second or third week.

By knowing how much work (effort) has been put into the task and getting the ETC (work remaining), you would know the answer.

The most important reason, though, that percent complete fails as an early warning indicator is that it rewards bad behavior.  A programmer can get a task to the 80% or 90% state and feel good.  They may have put in 20 or 30 hours, but have a stumbling block removing that last almost inconsequential error that would allow them to declare it complete.  At that point, they can get a lot more satisfaction – positive reinforcement – by getting another task to the 80% or 90% state in the same amount of time that it will take to complete this task.

ETC works effectively because the reward scenario is exactly opposite.  If the task owner gets to that point where there are just a few hours remaining to complete the task, they can get a lot more satisfaction for completing the task rather than starting a new task and having multiple tasks with just a few hours remaining on them.

If you do have to use percent complete – and sometimes we just can’t avoid it – there is a best practice that alters the reward system.  Instead of allowing the task owner to estimate percent complete, use a rule-based system such as:

·         Before the task starts, it is zero percent complete

·         Once started, it is ten percent complete

·         If it is near completion, it is 50% complete

·         Only when it is complete complete does it get set to 100% complete

With this approach, task owners, from my experience, are much more likely to complete their tasks without letting them drag on indefinitely.  This may not be a 100% fix, but, with apologies to Arthur Conan Doyle, it is at least a seven percent solution.

Do you have any examples of good or bad early warning systems?

Ode to ETC – The Task Overrun Early Warning System

History is a vast early warning system.

                                                - Norman Cousins (15Apr1978)

Sometimes you have to use the tool you have available, whether it is any good or not.  So it is with getting task completion status as percent completes.  Much better though is using the best tool for the job.  This blog exists to share project management best practices, so today I extol the virtues of ETC.

As PMs, our job includes delivering a project according to plan, knowing when the project is off plan (and acting to get it back), and communicating status to stakeholders.  Other people – our project team mates – do the important work and we rely on them for the information to do our job.  To be successful, we need a tool that helps our team mates communicate that information and for us to receive it accurately.

The well-defined task is the starting point.  Knowing whether the task has not started, has started (is in progress), or is completed is beneficial.  It helps us with history, with past events, but doesn’t communicate enough about the future.  Looking back is easier and more comforting, but it’s not the most beneficial nor the most important activity.  The most important objective with task status is to look forward, to be able to determine that the task will progress to plan.  Only by looking forward effectively are we appropriately serving our stakeholders.

The best tool for tracking progress is Estimate to Complete (ETC).  ETC works best when tasks are estimated, scheduled and reported by effort (as they should be), but even with duration scheduling is still superior to other methods of communicating what remains to complete the task.  When you ask the task owner “How much more work is (or how many more hours are) required to complete this task,” it forces them to re-estimate the remaining work, but with the advantage of everything they’ve learned by progressing to the current state.  The values get progressively more reliable.  Further, as the task gets closer to completion and the ETC value gets smaller, the task owner has an incentive to complete the task (just to get it off their plate), as opposed to the negative incentive system with percent complete reporting (see my next post).

No predictive system works effectively if it is rule based.  That is, if the task was originally estimated at 40 hours and the owner has completed 24, they can’t satisfy the ETC just by reporting 16 hours to go;  that defeats the predictive value of the technique.  They have to actually re-estimate the remaining work, which could be more or less than 16.  Tip:  be very suspicious if a task owner just keeps reducing ETC by the number of hours worked on the task.

ETC, when used consistently and properly, is a PM’s best friend.  ETC is an early warning indicator into task delays, under-the-cover scope creep, or a task owner that may be over their head or not performing.  As an early warning indicator, ETC is much more reliable than other methods.

One thing I’ve found using ETC is the necessity to frequently reinforce that the task owner must re-estimate the task each week.  Do you have any examples of problems using ETC?