Estimation Units Predict Schedule Slippage

I’ve been teaching a project management workshop, and one of the participants said something brilliant: “If you estimate in days, you’ll be off by days. If you estimate in weeks, you’ll be off by weeks.” If you estimate in months, you will be off by months.

Here’s why. The more you can break a big task apart, the more likely you are to remember all the pieces and estimate each piece well. The less you know about a task, the more gotchas you’ll encounter, and the longer the task will take. And, the bigger the task, the more likely you are to fall into student syndrome.

If you’re a PM and you don’t understand why your schedule is slipping, look at the general task duration. Got a lot of week-long tasks? Or multiple-week-long tasks? Those tasks are slipping, and you won’t know why or by how much until the time is almost done. I bet your project will slip for a duration of several of those multi-week tasks. Replan now, breaking all those tasks into inch-pebbles. Then you’ll have a much better idea of what it will really take to finish this project. And maybe, just maybe, you won’t have that much of a delay, because delays of weeks are very different than delays of days.

About Johanna Rothman

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

2 Responses to Estimation Units Predict Schedule Slippage

  1. I agree. The last major project I worked started with the manager stating that the smallest task on the project was 400-person-hours long. One person working ten weeks – that was the SMALLEST task.

    Many schedule problems ensued over the next two years.

    Finally, we replanned the project. We worked hard at monitoring each individual day in the work. Everything finished on time or ahead of time.

    Why didn’t we do this day-by-day planning at the start? No one wanted to do that. It was so much work and it didn’t seem to make any sense.

  2. John Salch says:

    I agree, as well. However, I have also found that estimates can be too small. Certainly weeks is too big, but estimating how long you will spend doing a single check-in (maybe 2 minutes) of a file is too small.

    Estimation takes effort and time. The more granular, the more time it requires. There should always be an “effort vs. value” thought process applied.

    One other aspect to consider is that the more granular the estimate, the more perfect it is expected to be, and thus the more resistant to change people become. Story points can be handy here, or “perfect engineering days/minutes/hours”.

    Care must be taken in these processes. Small iterations, such as 1 week (in XP), really help. Detailed planning can be done but only for a short horizon. Less granular planning can be done over longer horizons…

    For more information on all of this, Mike Cohn’s book “Agile Estimating and Planning” is a great resource…

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>