Percent Completed Myth

RandyStafford, on ManagersViewsOfDevelopers, made this point:

: ... "percent complete" of a task is a ridiculous progress metric.

: Tasks have only three states: not started, started but not finished, and finished.

: It is reasonable to ask for an estimate of the remaining (uninterrupted) time to complete a task (i.e., ETC - see Completion Headroom in http://c2.com/ppr/episodes.html), but a much better progress metric is percentage of use cases / scenarios that pass acceptance tests. Use case scenarios are either implemented, or they are not.

: So, if 10 of 25 use cases pass acceptance tests, it's not 40% complete? If 10 days have been spent and 10 more are predicted, it's not 50% complete? What is the "myth" here?

The myth is that the amount of work remaining can be determined by a simple calculation of the total work minus the work done. However, it's often the case that after working for 10 days, you may predict you will take 10 more days, but in fact you may have done much less or much more than half the total work required. Those 25 use cases are unlikely to all require exactly the same effort, so it's a myth to believe that the time taken to complete 10 use cases to acceptance tests is 40% of the total time it will take to complete all 25. The 40% is a mathematical fiction. -- StevenNewton

So, why is it "a much better progress metric is percentage of use cases / scenarios that pass acceptance tests"?

Because of the LawOfBigNumbers?. If you have 20 use cases that you believe have the same level of complexity, after you finish 10 of them you are very near 50% done - you may be 40% or 60%, but certainly not 80% done. This happens because some use cases will be a little harder and some a little easier, and these deviations from the norm will tend to cancel out.

This assumes you estimate well how much time you spend in your "average" use case, but even if you don't, this approach allows you to adjust your estimates mid-course. Let us suppose you are a ProjectManager that didn't estimate well your "average" use case in the beginning. You thought it would take 1 week to complete each of the 20 use cases, but you only hit the 50% mark after 15 weeks. You have some time to ManageExpectations? or even call for help from a senior DreamTeam.

On the other hand, your buddy ProjectManager didn't care to split a similar project in smaller chunks, but set the same schedule: 20 weeks. After 15 weeks, everyone is confident they are "80% done, boss!", and that they can make up for some "minor" slips. By the middle of week 18, panic strikes the team: "Oh my God, we are doomed!" By now, it is too late to do anything but to push the deadline a month further. This is repeated until SomethingAcceptable? is delivered or the sponsor decides to PullThePlug?.

... "percent complete" of a task is by no means always a ridiculous progress metric. It depends on the nature of the task. If you are mowing the grass and the lawn is half-mown, it is far from ridiculous to state that the task is 50% complete. That assumes, of course, that you are only mowing the grass. If the task includes trimming the edges and collecting the cuttings, who knows how complete the task is?

If you had an initial view that trimming the edges would take as long as mowing the grass, you could argue that the task is 25% complete. But let's say that you have taken 20% longer to mow the half of the lawn that has been mown (disregarding, for the sake of simplicity, the initial start-up sub-tasks, so reckoning from the onset of mowing, in both the original estimate and the "actuals to date"). Now, discounting any "exceptional circumstances" that account for the difference, you might reckon that the overrun will apply equally to the remaining 50% of the sub-task and to the other sub-tasks, so it is still fair to say that you are 25% complete. On the other hand, you might argue that the overrun applies only to the mowing sub-task, so the trimming sub-task will take no longer than originally estimated, so you are 27.37% complete. Or you might observe that mowing varies with the area, whereas trimming varies with the perimeter, and it is your estimate of the area that was faulty. For a square lawn, a 20% increase in area implies a less than 10% increase in perimeter, so you might be 26.1% complete...

For a single-person task, you can define percent completed as the time that you've spent on the tasks divided by your estimate of how long the task will take. You can estimate that a task is 60% (or whatever) complete. That's a lot more comprehensible to your manager and coworkers than providing an acceptance test percentage or saying that you finished internal pieces A and B but not C. -- JaredLevy

Shouldn't that be the other way round? Isn't it more meaningful for your manager and coworkers if you tell them "Feature A,B is done, but I am working on C"? Your coworkers can try to integrate with A and B, your manager can have contingency plan for releasing the product without feature C. What useful information can your coworkers extract from "My tasks are 60% complete"? What kind of contingency planning can your manager do from "60% complete"?

I think so. See InchPebbles

It doesn't sound as though the participants here have been involved with the business/financial end of a FixedPriceContract (as opposed to TimeAndMaterialContract) project contract yet. For a FixedPriceContract with a substantial front-end payment, there are very rigid accounting standards - many reflected in law - that require a PercentCompleted? estimate (myth or not) in order to determine how much of the front-end revenue may be recognized as revenue (sometimes called RevenueRecognition?).

Mythical or not, the approach is not totally insane: if I receive a $30M front-end payment to secure a $60M 36 month project, I cannot claim the full $30M as revenue the same week I receive the check. Instead, according to multiple accounting approaches (of which the company must choose one in conjunction with their auditors), I must essentially put the money in escrow and then draw against it as my company progresses against a schedule I've put in place. Processes are also in place for making the schedule longer and shorter, and management will adjust its demands on the project team based on whether they want to see more or less revenue recognized.

For example, see http://www.acsondhi.com/revenue.htm for a relatively typical outline of the issues involved.

What this says is that the PercentCompleted? metric is useful for large organizations dealing with large FixedPriceContracts, but not that the metric has any bearing on reality. What does that say about the efficiency of the organizations involved?

The accounting issues are just as real and probably more immediate when dealing with a $60,000 six-month contract and a $30,000 front-end payment. Which part of this doesn't apply to small organizations - even individuals - dealing with small FixedPriceContracts? None of this strikes me as remotely related to a discussion about a relationship, if any, between an organization's size and its efficiency.

Perhaps efficiency was the wrong word, then. What I meant to ask was this: What are the forces that make an organization decide to choose the FixedPriceContract, and its right-hand-man, the PercentCompletedMyth? Is scale in anyway related? My guess would be yes, since larger budgets increase the fear, and hence the desire for false reassurance.

I know of more than one graphic designer who's had to eat hamburger-helper for weeks because they spent their 50% front-end money the first week and found themselves with ten weeks of work before they could finish the job.

As I see it, the primary force driving a consumer towards a FixedPriceContract is a desire to limit exposure to risk. So long as risk is part of software development, the costs associated with risk will have to be apportioned in some way between the consumer and the supplier. I don't see scale playing a significant role.

% complete is a pure concept. Someone's guess is someone's guess. They are both useful together.

The concept of "percent complete" isn't a myth. Sometimes, however, estimates given by developers are mythical (or pulled out of the air), frequently for one of several reasons:

The developer doesn't know, states he doesn't know, and the boss doesn't like that answer - so he makes one up.
The developer doesn't know, doesn't want the boss to know he doesn't know, and makes one up.
The developer knows, but thinks the true answer ("I'm going to be three weeks late") will provoke a negative reaction on the part of the boss.
The developer *thinks* he knows and may or may not be surprised that week after week progress is still at 90%. See below. -- JasonNocks

Management should always EncourageHonesty?, not EncourageDishonesty?.

I'm surprised that nobody has mentioned the most common PercentCompletedMyth. When developers are asked for their estimate of how far along they are on a current task, one of the most common answers is NinetyPercentDone. Many developers often get to what they think is NinetyPercentDone complete almost immediately and remain at NinetyPercentDone until the task is done. They probably truly believe that they are *almost done*, but don't have any data to prove that they are right or wrong. -- JasonNocks