Ninety Percent Done

A synonym for AlmostDone -- i.e. not done. Very rarely will you find that the person claiming to be 90% done has actually done the following:

Made a solid, defensible estimate of the time/effort remaining;
Compared it to the work which is complete so far;
Verified that the ratio of work completed to total work is indeed 90%.

Also, estimates of 90% done should be viewed with suspicion in light of the NinetyTenRule (or EightyTwentyRule). Often, this claim means "the 90% of the work which takes 10% of the time has been completed; the remaining 10% of the work is not done yet."

A ProjectManager, when receiving a report that a worker is 90% done, could do worse than to reply as follows:

"Let me see. You've spent 10 days so far on this task and are 90% complete. That implies that you have about 1 day's worth of work to go. Can I count on you to have it done by tomorrow at closing time?'' Round the additional time needed to the nearest day/week as appropriate, of course.

If the developer says "yes", you have a new commitment to track (rather than a wishy-washy estimate); if the developer misses that commitment then other actions must be taken. If the developer says "no", and resists that commitment, then the 90% completion estimate was bogus to begin with, and a more realistic estimate can be worked out.

Who says the estimate was bogus? Can you guarantee you won't be sick tomorrow? Will there be meetings or training etc? Even an accurate estimate does not mean the manager can rely on it being done on time. And this does not even take into account the times that things just plain go wrong.

An estimate means that, a (good faith) estimate; not an iron-clad, you-can-have-my-firstborn-if-I-fail promise. Absence due to illness or similar circumstance beyond the developer's control ought to always be excused, of course. Regarding the other things that go on in the normal workday, a good rule of estimation is to provide the expected amount of time it would take assuming the normal amount of overhead, distractions, etc. In other words, estimates should not assume the developer is barricaded in his desk and doesn't have to attend meetings. And even barring that things can go wrong, certainly. A BugFromHell may crop up. It may just take longer than expected. If a developer is a day late on a particular task, it shouldn't be problem. If everything he does takes twice as long as he says, that is a problem (though the ProjectManager might consider a ScheduleCorrectionFactor).

All too often, when an estimate is being made, it means "the earliest time you can't absolutely prove it won't be finished." Then, once the estimate has been made, it suddenly becomes the time when Very Bad Things will happen to you if it isn't done.

I have personally been involved in two embedded systems projects that were supposed to be "90% done" (or more!) before I picked them up. In both cases the hardware was barely able to perform the required functions at all, and in one case the underlying electromechanical system couldn't meet the speed spec if it were pushed off a cliff, much less running under normal conditions. Both of these projects required testing of the electronics and electromechanical hardware to verify that the platform would or would not support the software properly. Both projects ended up having their multiple-man-year software sets ashcanned. Both projects ended up in the dumpster after having been given to Yet Another Engineering Consulting House.

They were 90% done, though.

-- MartySchrader, purveyor of many such horror stories -- just ask!

I see two kinds of 90% done projects in the field:

All features are 90% done
90% of all features are done

The latter is a much better state for a project to be in: you can deploy straight away and will probably meet all the user's most important requirements (EightyTwentyRule), but 90% of projects I see are in the former state.

--NatPryce

See: OneHundredPercentDone

CategoryHorrorStory (heh), CategoryScheduling