Johanna warns us that there is “no such thing as percent complete” when it comes to tracking status on a project. Your managers and customers want to know percent complete – and there is a way to report it. Project planning and scheduling involves walking this fine line.
Nothing Is Done
There’s an interesting problem with reporting percent-complete status on tasks. How do you know the percentage of completion?
The more serial your lifecycle, or the more you implement by architecture instead of by feature, the less completed work you have. Since I don’t count partially completed work, it’s possible to have 0 progress until the very end where things finally start coming together.
There is No Such Thing as Percent Complete, Johanna Rothman
Another factor that can cause this to happen – bugs. When your approach is to write until the code is “done” and then test it, you’re assured that this will happen to you. If you take a continuous integration approach to testing, you can eliminate the influence of quality issues on this specific phenomenon.
Some Things Are Done
Johanna has a valid point when it comes to individual tasks. However, you can still report the percentage of the tasks that are complete. And you can even weight that percentage based on the estimated effort of each of those tasks. This helps you demonstrate some velocity during the project without misleading yourself.
I once heard someone say “We’re 80% Done, with 80% Remaining.” Sorry for not remembering who said it. Definitely an experienced software professional. [Update: One of Johanna's commenters had heard this too, and referred to it as "a classic", so no one knows who said it.]
In another article, Johanna recounts a similar experience:
At the end of the first week, I was 20% done. At the end of the second week, I was 40% done. At the end of the third week I was 60% done. At the end of the fourth week, I was 80% done. Right on time, at the end of the fifth week, I was 90% done. At the end of the sixth week, I was 92% done. Seventh week, 93% done. Time and I both marched onward. At the end of the 10th week, I was 97% done. But this time, I actually believed I was within a week of being done — I only had three one-day tasks left to complete. It took me two more weeks. A total of 12 weeks for a 6 week task.
90% Done, Johanna Rothman
Estimate With Small, Tangible Deliverables
The key thing to track when estimating development work is to track things at the proper level of detail. We have always used tasks in the 2 to 8 hour range. The range is set to 1) avoid too much overhead on tracking tiny deliverables, and 2) to avoid this exact problem by deluding ourselves about poorly thought-out activities.
There are three benefits to this estimation approach.
- Decomposition Equals Planning. By decomposing a 40 hour development task into half a dozen discrete deliverables, you force yourself to think about design and execution. If you blithely say “8 hrs design, 8 hrs refactor, 8 hrs implementation…” you’re doing yourself a disservice. You might be following the letter of the law, but not the intent. This planning (which qualifies for “as little as possible” planning when you’re being agile) helps to organize both your work and your thoughts. Different people work in different ways, so this will benefit some more than others – but it benefits every developer. And plans don’t prevent changes unless you let them.
- Deliverables Demonstrate Progress. Having discrete deliverables lets you know up front how you’re doing. And it lets you know early on if you’re having problems. Although we didn’t discuss the math behind it in our tutorial on creating PERT estimates, when one tasks exceeds the estimate, other tasks are likely to do so as well. In general – each pert estimate is a representation of risk, quantifying the factors that would cause a task to vary from the estimate. Each estimate is created independently – but they often share the same risks. Imagine that the same risk applies to two tasks. The first task runs 50% over the estimated time, due to that factor. Do you think the second task is now more likely to exceed the original estimate? This will help you decide the cost of delaying the release.
- Consistency Creates Credibility. Reporting repeatedly on the status of deliverables lends credence to the overall plan. It establishes credibility with your customers / managers. It also removes some of the mystery from the black box of “this release will be late.” You can communicate “this deliverable will be late.” The end result is the same – the release is late – but now you have a framework for discussing and addressing the cause of the delay.
Conclusion
Don’t “track” monolithic tasks with percent complete. You may need to report percent-complete on monolithic “roll-ups” of multiple tasks to managers – that is fine. Make sure you’re tracking the individual tasks (or that you trust the people on your team to do that and roll it up for you). Don’t use this article to enable micro-managers. Use this article to avoid deluding yourself about the actual progress on your project or release.
Latest Articles
Comments on all Articles
