Project Estimates

Published 5 Comments on Project Estimates

My experience with project estimates and scope can be summed up by the following chart.

Of course the actual chart has way more uphill bumps and a much longer tail. But basically, the project starts, then you realize you didn’t scope it out entirely. Then some progress happens and you realize you totally forgot an important use case. So it’s back the infrastructure to make it right. Then alot of progress. Finally, the last 5% of the project takes 25-30% of the total time to complete the project. That last 5% is where the perceived value of the project literally doubles. See the following chart.

This phenomenon is sort of like building a car. Imagine you have an assembly line with all of the parts of the car coming together. At any point in the assembly, the car is worthless to the user. It is not until the last moment when you hook everything up together so that the car can MOVE that you realize the full value of the car.

In technology projects, you often can perform certain tasks midway through which give some perceived value. In my experience, I have found that the last 5%, which is also the long tail which takes 25% of the entire project schedule, is the part of the project where the user realizes the potential and puts a high value on the product.

What does this all mean? It means:

  1. Be comfortable with the fact that all projects go up in estimated time to complete at some points.
  2. Schedule ample time for that long tail. It is always there. If you skip it, you end up with a crappy looking, half-baked app.
  3. Expect perceived value to be 1/2 normal at 95% complete.

Side note: Making charts is fun. Ethan says that Charts are the most important thing in the world.


  1. hey glen,

    so coincidental you’ve written this post now. last night i hit chapter 3: ‘initiating interactive projects – scoping the project’ of managing interactive media ( your blog, with all its graphs and charts, looks so timely as i embark on my final year project for uni.

    i think you’ll remember me from your kind help on the jquery forum:

    hope you’re well!

  2. If you know that (or if there is a significant assumption) that there will be this point of where you realize that you didn’t scope it out completely, shouldn’t that be part of the original project plan. Or is it a bad move as a professional to formally write on paper (before the project) that you anticipate that you are forgetting something. From one perspective, you should believe that you anticipated everything in the beginning and built in contingencies; however, if this is really not going to be the case, wouldn’t it be a more responsible business plan if it have something in it about unforeseen issues (and thus you could have already allocated time and resources for that). Understanding and accepting certain weaknesses is a very difficult although effective method to planning.

  3. @Tom, cool books, I will check them out.

    @Lewis: Awesome. If there is anything I can do to help, please let me know. My own book writing is going so slow, but I really enjoy helping others.

    @Dan: This is why people pad their hours. Basically, I feel you should not plan the “Schedule” for the entire project at all. Agile methodologies like Scrum and XP work very well by estalishing a heartbeat. They establish a method for estimations and a way of ordering the tasks. This heartbeat is WAY more reliable than gantt charts.

    Although the chart is a good reflection of my personal experience with technology projects.

Whatya think?