Recall your last few project status meetings. The project manager reviews the open tasks and asks for progress. The technical team reviews and responds with answers such as 50% complete, 90% complete, 34.7% complete, etc, etc, etc……. but what does it all mean?
Anyone who has worked in software development knows the old saying: 90% of the work takes 10% of the time and effort. The last remaining 10% takes 90% of the time and effort.
Tracking progress by percent complete is misleading and inaccurate at best. It is often a subjective scale, easily influenced by personal bias and generalization but it is the most common progress tracking tool that exists in the industry. Tools such as Microsoft Project are based on % complete. Analysis such as “Earned Value” is based on % complete. Management reporting and dashboards are based on % complete. With so much information based on percent complete, do we actually get the right picture, or do we get a biased view that can represent a false picture?
Imagine the following scenario:
Task A is estimated at 10 days. After a week, during the status meeting, the developer announces that he is 50% complete. 5 days out of 10 day estimate, 50% complete, we are right on track. Another week passes by and on the next status meeting, the developer announces that he is 90% complete but he hit a little snag and have just a little bit more to finish. What does it mean? Is he 1 day away from completion? 2 days? A week? Or maybe just an hour?
Technical people measure effort by the amount of work they have to do while project managers usually measure effort by the amount of time and budget that are needed to complete the work. Most times there is a correlation between the two, but “most” is not always and “most” can get us into trouble with little or no warning.
But what if we turn the question around? What if rather than track progress by how much we completed, we track by how much work is remaining? Rather than ask what percentage was done we ask how many days/hours/weeks are left for work to be complete?
Let’s look at the same scenario again but this time the project manager will not ask how much progress was done but rather ask about the time left:
Task B is estimated at 10 days. After a week, during the status meeting, the project manager asks the developer how much time is left. The developer answers, I have 50% of the work done and I estimate that I need another 6 days to complete. At this point, the project manager’s ears should perk up. 6 days will bring us over the estimate and the task might need additional attention. The PM knows that he cannot wait for the next meeting and might need to check on the task more often. At the next status meeting when the developer announces that he is 90% complete but needs another 2 days to finalize the work, the PM has already made contingency plans and can address the schedule slip accordingly. Using the “days remaining” approach can give the PM early warnings that might not exist in the Percent Complete approach.
Learn, grow and expand your BPC interests by registering for one of our upcoming webcasts!