For years now, I have been attending project status meetings where people go round the room asking each other variations on one question: “What percent complete is your work ?”
“Percent complete” has negative connotations in Scrum as also in the PMBOK. Managers who use percent complete are viewed as ignorant at worst and old school at best. Why is that ?
One argument given against using percent complete as a measure of project progress is that it is arbitrary. It almost never comes from hard numbers and is usually given by someone who has been put on the spot during the dreaded team meeting.
Irrespective of how many project management books deride the usage of percent complete, I see a natural tendency among managers to go for it in every team meeting. This is probably because it spares the manager (and his PMO) the trouble of digging up numbers.
One interesting compromise I have seen in this aspect is the usage of milestones. The idea is simple: instead of depending out-and-out on a developer’s idea of percent complete, the managers suggest that we have milestones for 25%, 50% etc complete and mark these “finish” based on a detailed review.
Here’s an example:
A tester has been asked to prepare a Test Case Document (TCD). He provides an estimate of 100 hours for completing this document. The project manager creates an activity called Create Test Case Document (CTCD) against which the tester logs his hours worked. In addition, the manager creates milestones (milestone activities in some project management tools) which stand for 25%, 50% etc completion of the TCD. Based on the weekly status reviews, the tester and the manager together decide if they should mark the document 25% complete or 50% complete etc. The project status report then draws directly from these milestones to specify (mostly to senior management) how much of the TCD is complete.
This technique has the curious effect of making it appear as if the status was based on hard numbers instead of just a subjective discussion between the tester and the project manager. Given that, I believe that this brings in some objectivity to the project. More importantly, it forces the project manager to take a closer look into the activities because he is responsible for marking a milestone complete or otherwise.
As means of variation, the number of milestones against each activity could be increased or decreased depending on the granularity and accuracy desired in the status reports.
Let me know if this makes sense or if you have used similar techniques in your projects.