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?
No comments:
Post a Comment