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.

The 90% done schedule game is the reason I like feedback during project work, in the form of inch pebble estimation, one-on-one meetings with managers, visible project status, and project-wide rolling wave planning.

About Johanna Rothman

I help managers and leaders do reasonable things that work.
This entry was posted in schedule games and tagged , , , , . Bookmark the permalink.

8 Responses to Schedule Game #2: 90% Done

  1. Ethan says:

    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.

  2. Jason says:

    I bet the 90% game is directly related to the fact that I always underestimate by a factor of 2.

  3. Democritus says:

    Zeno’s Paradox, right?

  4. Dave Smith says:

    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.

  5. James Thiele says:

    A clasic statement in software development is that the first 80% of the job takes 80% of the time, and the last 20% takes the other 80% of the time. Feel free to use 90% and 10% if you prefer.

  6. Pingback: Agile antipattern: But the development lead said it would take way less time than that

  7. Paul Komar says:

    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.

  8. Paul, this is why I started using inch-pebbles. It’s why I use work hard to break stories down with agile teams. It’s why I have tasks for me that take no longer than an two hours.

    The schedule games are evergreen. We have different schedule games in agile, but the larger your tasks, the more we have to estimate. The more we estimate, the more we have schedule games.

    I stopped estimated. I no longer have schedule games. It’s a different problem now. (Hmm, I should blog this, huh?)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>