Last night at mytalk someone came up to me at the end of the talk. I'd discussed earned value and inch-pebbles in my talk but hadn't specifically discussed how to avoid the dreaded “percent complete” reporting problem to management. The percent complete problem occurs when you have to report progress to management as “the project is x% complete.” In my experience, the x has two values: 50% and 90%. The project doesn't stay in 50% too long before it goes to 90% 🙂
The problem with percent complete is that it might reflect % used of the schedule, but it doesn't reflect the actual project percentage complete. To understand actual completion, look for earned value (how much you've accomplished based on completed work) or at the number of inch-pebbles completed.
Earned value works very well on agile projects. Agile lifecycles deliver value at the end of each iteration. It's possible that a subsequent iteration will reduce the previous value by some small amount, but during that iteration, the value is increased by implementing some other feature. Here's an example. In iteration 2, the form was “completed,” (as was the underlying database schema) to the best knowledge of the developers, testers, and customer. As the customer reviewed the user stories for iteration 5, the customer realized he needed to remove one field and add another field on the form (with appropriate database changes). In iteration 5, the form and the database were changed, initially reducing the earned value (removal of previous feature) and increasing earned value (addition/modification of previous feature). (If this is still confusing, send me email.)
Earned value works well when you have independent product parts — parts that don't completely change when other pieces of the system changes. Agile lifecycles, along with staged delivery, design to schedule, concurrent engineering, and evolutionary delivery allow you to calculate earned value. If you use a true waterfall, you can calculate earned value, but I've found that the value of the early documents is not as high as code delivery (earned value is not even across the project). If you use a spiral lifecycle, you can't calculate earned value because you're allowing for change across the entire project every iteration.
So if earned value doesn't work or you're not willing to calculate it, consider inch-pebbles. Inch-pebbles are one- to two-day tasks that are either complete or not complete. No percentage complete allowed! If you add up the number of inch-pebbles and look at how many of them are complete (8 out of 100 inch-pebbles complete), you are roughly 8% complete. You could still be off, especially if your inch-pebbles at the beginning are smaller than your inch-pebbles at the end. Or, if you're like me, and you iteratively plan the project, you have no idea how many inch-pebbles you have throughout the project, you only know how many you have for this phase.
Whatever you choose to do, make sure you don't use percent complete. Percent complete leads you astray, into the 90% complete problem. (After you've done 90% of the project, you have the other 90% to do.)
When you discuss project progress, make sure you're looking at all sides of the project pyramid so that you explain how the assigned people are using the budget, time, work environment to produce the product with it associated defects. That's the most effective technique to discuss project progress.