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.
Hey y’all – I got the following great question in email –
Construction projects allowed larger better understood items, because they had been done for many decades, and as you said – they are concrete deliverables (pun intended). When you pour a large foundation, you know it will take 2 weeks to cure, with a near-zero chance that you will have to tear it up, remix and repour because you forgot to put the rebar in place first. So you can present that knowledge. The foundation might make up 20% of the total build time for a pre-fab structure.
Here are some construction examples that might mirror software development:
I think the key thing is that you can estimate percentage of deliverables that are complete. And the estimated time for remaining deliverables is the “best info you have.” If you don’t review the deliverables, it would be like saying “this project should take 6 months – therefore after 3 months, it should be 50% done – with no way to confirm it. With construction projects, you have those confirmations because you have the concrete deliverables.
Great question, and thanks for the continued reading!
Hello,
There is a slight misunderstanding here, imho. A construction project is divided in two phases: design and then, construction. For software development, we have the same paradigms. The design phase, and then the “construction” of the software (compiling, building assets).
While the compile time is very well known in the software industry (as the building time), the culprit here is the design phase (architectural phase in construction). As like software development, It’s not uncommon in the construction to have dead line problems if you include the design phase…
The best way to measure percent complete on any project is to have a measure of output as time spent on task loosly correlates with output. Unfortunately, the software community finds the use of output metrics inimical to good software develpment — especially lines of code.
On my own software projects, I have estimated output and tracked output against time with excellent results. My favorite measures are LOC, Defect Count, and Defect Fixed. Before the project starts I estimate LOC and expected number of defects to find and to fix, and then as I execute the project I proceed to track against those estimates and contrast them to effort expended as a percentage of budgeted time.
For those who give this a try, they will find the amount of control they have on their projects to be unsurpassed by any other techniques. The common arguments are that it’s impossible to accurately predict LOC and Defects, but that isn’t the point. The objective is to control your project, and even though the precision isn’t 100%, it still is able to tell you that your assumptions that the project plan is based on are wrong, and it tells you that early so you can do something about it, and thus, control your project.
Hey Bill, thanks for reading and commenting!
I think your system is a good one, but generally, any rational approach to tracking of output – consistently applied – will be valuable.
I don’t have the data to back it up, but it seems like I write the most lines of code in the earliest part of implementing something, and it isn’t a linear relationship. The first 20 lines of code may take 10 minutes, and the last 2 lines of code may take an hour. But your point is valid – and if I consistently see that, I can account for it in my forecasts.
Thanks again.