One of the most interesting project management reports that evolved after my start in the industry is the “burn-down” report. I 
mention it because at HMS, we are about to launch TimeControl 7 and we are in the final hours prior to launch where we are at the end of a long reiterative burn down process.
If you’ve never been in the IT industry then you may not have seen such a project management report with this title but the concept is not unique to the IT industry. In construction project management we tend to think of this as the “Commissioning List” or the “Commissioning Report”. It’s a list used in the final stages of the project of everything that is incomplete. In construction, you have a list of things you know need doing, but as you walk the project in the final weeks, days or hours, you and your staff keep a list of things that you notice. Paint that didn’t go quite to the end of a corridor, a pipe that is exposed but was supposed to be hidden, refuse from a contractor that was never collected… And so on.
In my world in IT, we have a list of outstanding items that have been discovered in the QA process. Code for our next version was completed some time ago and numerous people are working through the product over and over and over trying to make it break. Each time they do, or they find a discrepancy of any kind, they list that in the outstanding list of things to resolve and that list becomes the count of items in the burn down report.
As you can see by the example here, the reason it got the name it has is because you keep hammering at the report day after day, trying to burn the list down to zero.
One of the aspects of this project management report that I find fascinating is that a single view of it is not reflective of the entire process. It is the progression of the report that is useful.
When we start a burn down report early in the QA process, it is not uncommon to see the numbers of issues rise. In fact, if we start the report too early, it may rise very quickly. For the uninitiated, this can be disturbing. “Why is Testing finding so many problems?” management may ask. They shouldn’t be upset. Every issue you find in the lab is solved with a tiny fraction of the time and heartache it will take to solve the issue once the product is released.
In a normal process, the report tends to looks like rolling waves that get smaller and smaller over time. Some reports, as are ours, show different categories of issues, some lump all the issues together. We prefer to show the critical issues distinctly from the less critical issues. We have to resolve them all of course, but reading and analyzing the report gives the senior staff a good idea of where the product is going.
Let’s say that as you are getting near what you believe is the end of the QA process, new critical issues continue to be added. You should take caution that you aren’t as far along in testing as you should be.
On the other hand, let’s say there has been no report of any critical issues for some time and the moderate issues have died off also. What is left are the low-priority issues and even those are now approaching zero. We update all of those, do a new cycle and see if we’ve resolved those, make sure we haven’t broken anything else and check to see if we’ve burned down the issues all the way to the floor. We’re pretty much there with TimeControl 7 and as a result we’ll be packaging it and getting it to market in the next couple of days.
If you’re working through your own burn-down list, know that you have my sympathy and that there really is light at the end of the tunnel. Think of the satisfaction of printing that particular report and seeing a message that says “No data to report!”
Striving for nothing in this case is a worthy goal!
