It's 45% done.



At the AYE conference, mentioned below, I co-hosted a session on software project measurement. We had a simulation that gave an opportunity for the participants to explore measuring and the impact it has on development. The difficulties of obtaining good metrics and the what they might mean or not mean about project completion were exposed.

After I returned home I had a chance to read Jerry Weinberg's article Destroying Communication and Control in Software Development in the April 2003 issue of Crosstalk, The Journal of Defense Software Engineering. It is an informative article that illustrates some of the many ways that we fool ourselves about project progress.

One item that I noticed was in a section titled: Project Management Reviews. In this section Jerry suggests that the presentation of project status data that is not based on actual work is a common way we inhibit good communication. Specifically he says, "Above all, monitor and compare predicted and actual accomplishments, where accomplishments are strictly tested/reviewed work products and not abstractions such as 45 percent complete, and are not chunks too huge to see work products from one review the next." The italics are his.

What struck me was the use of the word abstraction. 45% complete is an abstraction? What a perfect way to describe what happens.

Imagine the following sequence: 'Hum. The schedule is 20 person/days. We just completed the ninth day. Things are going well. I think I will put into my status report that we are 45% complete.'

Sound silly? Not really. About two years ago, I heard this sequence (the number are slightly different) from a project manager of an Agile project. It is hard for me to count all the times that I have seen status reports that contained such abstractions. I have written them myself!

In the simulation at AYE, the developers managed to deliver within the target schedule after a 100% schedule slippage. After the simulation, the developers discussed how luck played a huge role in their delivery success. If one specific event had not occurred in a timely manner, delivery would have been late.

Agile practitioners cite the need for honest and frequent communications. I suggest that the honest and frequent communication of abstractions does not help. The data that we present should be based on real accomplishments. And we should always remember that Lady Luck watches over our shoulders every day.

Posted: Wed - November 19, 2003 at 08:03 AM      

©