Schedule Game #2: 90% Done

I was a fortunate young developer. In my first three months at work, I ran into the 90% done schedule game. I did it to myself.

I estimated a particular task was going to take 6 weeks. Of course, being an arrogant and naive developer, it never occurred to me to break the task down into inch-pebbles. (That would have told me whether I even knew what to do for the task.)

At the end of the first week, I was 20% done. At the end of the second week, I was 40% done. At the end of the third week I was 60% done. At the end of the fourth week, I was 80% done. Right on time, at the end of the fifth week, I was 90% done. At the end of the sixth week, I was 92% done. Seventh week, 93% done. Time and I both marched onward. At the end of the 10th week, I was 97% done. But this time, I actually believed I was within a week of being done — I only had three one-day tasks left to complete. It took me two more weeks. A total of 12 weeks for a 6 week task.

During the time I was 92%, 93%, 94% done, I wrote status reports to my manager, explaining I’d run into unanticipated problems and that I hadn’t estimated all the things I needed to do. He was lovely about it, and kept saying, “Ok, let me know your updated estimate.”

At the end of this task, when I was finally done, he was all set to move on. I told him I would be estimating differently from now on, with much more detail, and several deliverables each week. If I couldn’t give him a date to be done, was that ok with him. We talked and I agreed to supply a date with a risk factor with each estimate.

I wish I could tell you I became a perfect estimator then. I didn’t. I’m still learning to estimate. But I now know that when I think I’m 90% done, I’m probably only 50% done.

I’m not the only one. The 90% done schedule game can occur under any conditions: reasonable or unreasonable schedule, low or high risk technology. 90% done is about our ability to predict the future, to perform accurate estimation, and to understand — in advance — if we will be interrupted. Not a trivial problem.

Previous/Next Posts

7 Comments

I believe it was this very blog that also passed along the PM joke about “We’re 90% complete, we just need to finish the other 90%.”
The 90% completion “crawl” as described in this post makes me think of basketball. You have all of this time to play the game, and yet that final minute seems to drag on forever. I wonder if it’s because of the tenths of seconds winding down whereas normally the time clock reads MM:SS.
Same with the 90% thing. If your %-ile complete tracking system jumps in increments of 10, once you hit 90, there’s nowhere to go to show progress without flat-out closing out the project as “complete”.
I wonder if a better way would be to establish what the criteria is for each block of 10% before advancing the project status to that level.

I first heard “90% done” from a manager in the mid 70’s about a mainframe integration project that had been 90% done–or at least reported as such–for the past year. Nobody took the estimate seriously by that point, and “90% done” was used a code phrase for “They don’t have a clue about where they really are.” It wasn’t long thereafter that I first learned about Schedule Chicken.

When I was in high school in the seventies, my math and programming teacher told me to double my estimates and raise to the next order of magnitude.
I have not often found that tasks estimated to take one day actually take two weeks. But is it surprising that tasks estimated to take 6 week scan actually take a year?
While we may not know of any, let’s not forget that many projects are cancelled before they are completed.

Sadly, this post from over 8 years ago seems as relevant as ever. Then again, the “software crisis” was described in the 60s.

Subscribe to the Pragmatic Manager

Johanna’s Books

See Manage Your Job Search on Amazon, too.
See Hiring Geeks That Fit on Amazon, too.
Buy Now
See Manage Your Project Portfolio on Amazon, too.
Buy Now
See Manage It! on Amazon, too.
Buy Now
See Behind Closed Doors on Amazon, too.