15 responses

  1. Dina
    September 12, 2010

    Bruce, I always enjoy reading your blog posts!

    To the discussion re: who should make the estimate, I find that a collaboration is good solution. Yes, the programmers know the specifics of what each task will entail, but in the case where there are similarities to past projects will they remember the details of what happened before and what caused things to take longer or shorter (ha! shorter!)?
    Not likely, so this is where the project manager can help dig up the details and make sure all of the information is on the table before the estimate is made. I like to come up with my own guesses for some tasks and run them by the person who will be doing them, give them an opportunity to revise and then buy in that way.

    And yes, MS Project will not show you the estimation history of a task, but there is a tool out there that will show you this valuable “change over time” data that you mention. I can’t help but put in a plug for LiquidPlanner’s reporting tools, and wanted to include a link to a blog post by CEO Charles Seybold where he explains how this reporting benefitted his team: http://www.liquidplanner.com/blog/2010/3/16/data-is-and-always-will-be-the-best-teacher.html

    And just to add a comment to the discussion about the politics of estimating… this has a HUGE impact on project budgets. Especially these days where everyone is trimming their budgets, most times there is no point in showing a realistic estimate to the client, if you want to get the job. Lately our clients have been telling us that they want us to work on their project, but need it to be within budget X. If we can’t do it within budget X, then forget it. And, we don’t always have a lot of leeway with scope. These days its a matter of doing whatever is necessary to get the new work. So, I like to track ‘promised’ and actual, and make sure all are clear that we will very likely not be able to hit the promised budget.

    • Bruce Benson
      September 14, 2010


      “I like to come up with my own guesses for some tasks” – yes, I would often first work out what I thought the estimates would be (using historical data) and then get the estimates from the experts. This gave me a better basis for reality checking the estimates.

      “most times there is no point in showing a realistic estimate to the client” – this is a hard one. Maybe I’ve been lucky, but in every organization where we moved from “promises we can’t keep” to realistic estimates, the customers have never left us. In fact, they’ve always – always – noted that we were finally giving them good estimates. In one organization where I had finally gotten us to on time delivery, our company once again started to make unrealistic promises – in large part because our largest customer decided to “challenge” us by asking for more. This went on for awhile and so I finally decided to find employment elsewhere. At the final meeting I sat in on with this customer, their top bullet on their slides said something like “You are too nice – you don’t push back when we ask for something you can’t do.” When we never delivered on time the customer never mentioned us needing to push back on their demands. When they experienced us delivering when promised and then seeing it go away as we tried to meet their new demands – they decided they would rather have us meet our promises then “go for it” based upon their demands. This is always scary, to provide realistic estimates and information, but it has always been a successful strategy for us.

      Thanks for the info on LiquidPlanner showing how estimates change over time.



  2. Parallel Project Management Training
    September 9, 2010

    The couases of estimating errors are also political. We are under extrem pressure during bidding or when the business case for a project is being build to underestimate the cost so the project will get funded. once the project has started the true costs are out.

    • Bruce Benson
      September 9, 2010


      Absolutely. My experience is this kind of pressure is one of the top 2 reasons why “estimates” are inaccurate. While I’ve often been told “we’ll lose our customers if we tell them it will take that long” I’ve, maybe luckily, never seen it happen. More often I’ve had customers tell me “it is about time you guy started giving us realistic estimates.”

      Good point.


  3. Peter Saddington
    September 9, 2010

    Great article. It sounds like there needs to be more frequent adapting and estimating throughout the process so that more accurate estimates can be achieved. Remembering the past is important, but using the past to help predict the future (if your projects have the ability to do that) can be a great way to create consistency.

    • Bruce Benson
      September 9, 2010


      I would say that there needs to be more recordings (automatically, within project tools already being used) to capture what actually happens during a project. The “recordings” I’ve used successfully include meeting minutes, archived status slides, defect tracking records, old project plans, etc. These I’ve found to be great sources for getting accurate estimates – almost always more accurate then just the memories of the participants. The best estimators usually show up with records of past efforts showing how long things took.

      I’ve found most organizations to be very consistent in their performance, but it is rarely obvious to the normal observer until we’ve found a way to capture the actual detail (again, using “recordings” such as those mentioned above). During the typical hectic activity of a project, it is often hard to see the patterns, how things repeat, and how long tasks take. In one large organization it was not untypical for the experts to say “it takes us about 3 days to complete these type of tasks” only to find that the real, measured, average number of days to complete these type of tasks was 10 days.

      Good comment.


  4. Pierre Abdel-Malak
    September 8, 2010

    Good article.

    I concur that projects could fail because of poor estimating and the unrealistic expectations to meet these inaccurate estimates. Remembering the past and keeping it all organized will definitely help producing more realistic estimates.

    Predicting the future is hard and requires good facts and specifics about what to be done and how to be implemented; the more you know about how you intend to go about it then the more accurate the estimate is. Often estimates are required and ordered at very early stages with little information on what to be achieved; the past could help providing a quick order of magnitude, not estimate, to help a sponsor decides whether they have the budget for it and is worth pursuing further.

    A good representation and participation of the actual project team (developers, business analysts, designers, architects, QA analysts, PM, etc.) is essential to producing a meaningful estimate. Last, it is important to review and re-estimate the project on an on-going basis.

    • Bruce Benson
      September 9, 2010


      “the past could help providing a quick order of magnitude, not estimate”

      In many cases, even when a project has “a good representation and participation of the actual project team” they produce a bad estimate. This is common in organizations who regularly struggle to deliver projects as planned. When this conventional (and good) approach does not work as expected, I’ve found that using the past performance (usually, just the average) works very well. In every case where we’ve used it, it has out performed the normal bottom-up detail driven team provided estimate. “Out performed” means in these cases that they finally delivered a project/product on time and with good quality – where in the past they had rarely, if ever, had done so.

      So past performance can provide a very good estimate – but I primarily use it in organizations that are struggling with their estimating process. Even when an organization has a pretty good (i.e., accurate) estimating process, I still suggest they know their past performance and regularly compare it to their current estimates. If one day they see a big disconnect, like a project with a schedule never attained by any project in the past, it serves as a trigger to ask the question “why is this project different.”

      Excellent point.


  5. Perry
    September 7, 2010

    Timely post.

    I’m going into an estimating process with a client and I know they don’t have a lot of experience estimating.

    I’ve asked them to think of two estimates: if you were 100% on the project and if you were doing your day job but no other projects.

    That will help me get a handle on the prioritization of other projects, but your information will help them get to the estimate.


    • Bruce Benson
      September 7, 2010


      Yes, it can be very enlightening to ask them how well similar efforts have gone in the past (they may be reluctant to share this – or may only provide the “last” plan, which had 3-5 replans before it). Especially for a client who does projects only occasionally (say, every few years) this past record is often a better “ball park” then any estimate they will produce. While the projects themselves may be fairly different, they are often using the same people+processes+tools that they’ve used in the past. It is a bit unintuitive, but often this people+processes+tools has more to do with how long things take (and how much they cost, etc.) then the details of the project.

      Good luck.


  6. Charlie Schiano
    September 7, 2010

    Great article, agree 100% with 2 and 3, minor disagreement with #1. Estimating should be made by the developer and then questioned by the Manager. Unless the developers estimate their tasks, they will never buy into the development schedules.

    • Bruce Benson
      September 7, 2010


      “Unless the developers estimate their tasks, they will never buy into the development schedules.”

      I’ve only found this a problem when schedules are generally not very good. Using past performance in this way, the programmer’s know that the schedule is based upon how they’ve done in the past. In every case we’ve used this, the programmers would tell us something like “OK, that’s finally a reasonable schedule.” (Scrum velocity is also a good example of this – using past results to anticipate the most probable future.)

      Where I’ve let the programming team set their own schedule, I’ve often challenged them to “show” me evidence that what they propose is a doable schedule. When they ask me how they could “show” such a thing, I ask them to show me several similar completed projects where they’ve done it in about the same time frame. They often come back with an updated schedule, usually a bit longer than they originally proposed, and with an attitude of increased confidence in their proposed schedule. This way we get the benefit of both past performance and buy in.

      Excellent point. Buy in – and confidence in – whatever method is used is always critical.


Leave a Reply




Back to top
mobile desktop