21 June 2011

Estimates are redundant. Here's why.

Estimates are redundant for many teams these days, although many persist in estimating work.  Let's run through some estimating canon and then talk about why estimating is in certain circumstances redundant.

Projects estimate the work effort up front to discover the balance between technical performance (i.e. scope & quality), cost and schedule.  This helps hire the right number of people, set stakeholder expectations and make portfolio investment choices.

Alternatives to up front estimating are to time-box the solution with a view to cutting or extending the investment on an as needs basis.  Another alternative is to fixed price (low value, exploratory) or fixed scope (regulatory compliance) the project up front.

Finding the balance

Estimating is done to help assess the balance between cost, duration and technical performance of the target solution.  It is used as a tool to negotiate the sliders on those dimensions.  One pass at up-front estimating is typically not enough for the smart money, as you'll have an all-or-nothing approach to the solution.  That is, in the process of estimating assumptions are made about how to prioritise fast, cheap, of "solution rich."  What you need to do in these scenarios is to revise the estimates until the sweet spot between the project performance factors is discovered.

Once an estimate is discovered it can be taken to portfolio management boards and assessed relative to other project proposals based on value generated, cost and risk. But, why on earth are we doing so many projects that deliver such marginal value?  Surely a project is worthwhile or it isn't?

  • Conclusion 1: Too many trivial projects are created where the work would be better managed as operations.
    • Question: What makes people 'projectize' work when it's not special, unique, and all that project 101 stuff? 
    • Hypothesis: Lack of systems thinking, expertise, complex taxation rules and accounting practices.
  • Conclusion 2: Ongoing estimating has to be the default mode of doing business.  If you aren't revising your estimates at every steering committee meeting there is something suspect in your reporting.

Fixed resource (money & people)

Much software development, especially operational work, is done in a fixed resource way - essentially fixed pricing the work.  In the fixed resource (cost) model estimating helps understand team capacity and plan releases.

If you have made the commitment to fixed resources you can park estimating activity and focus on short cycle times to ensure as much value is generated as possible.  Focus on flow to increase delivery and you'll get more out.  Estimate and you'll waste energy and time (a finite resource) on analysis that adds no value.  Improving your estimating won't help you ship more.
  • Conclusion: If you are fixed resource, there is no value in estimating.
I have another point as well, where you take a people or team centric view of the project, planning the work around existing teams.  We've gone on for long enough so I'll hold it over for a post next week.


  1. Anonymous5:41 am

    I speak at a university course every year about project management and agile development. The notion that "much" of development is continuous improvement or corrective maintenance (undesirable features) is how many large commercial systems work. PayPal is one. This is a perfect fit for something like Scrum at the development level. Sales folks bring in needed features from the field, they are assigned a release and the team (which is planned at the beginning of the year) goes to work after making their estimates of the effort.

    But there are other domains, where an upfront estimate, and corrections to that estimate are needed for success. Standing up a new ERP system, deploying a software intensive support system for another deliverable not software related.

    In all cases some form of estimating and corrections to the estimate are needed. The form needs to be adapted to the situation. But when you're spending other peoples money, they kinda like to know how much and when.

  2. I thought that title might elicit a response from you. We agree on these points. Your papal example fits my second scenario.

    Wait until you see the post next week. An extension of the Papal scenario.

    The next step after that; how far out of solution development can you take this?

  3. Craig,

    Would you manage your own personal finances based on your own recommendation?

  4. I am not saying all projects can forgo estimates.

    On the other hand many things are labelled as projects which are really operational enhancements.

    Operational enhancements are usually managed by capacity rather than work based estimates. Why not apply the same principle to nominal projects?

    If I were funding these sorts of projects I'd certainly have a budget and it would likely equate to a fixed period (e.g. a year or quarter.) Prioritisation and limiting work in progress would go a long way to ensure that I get an optimal return on my investment.

  5. One way I have seen this done is to triage all project requests with t-shirt (gu)estimate. Anything small that is a change to an existing goes to a change queue where indeed a fixed resource pool works on these changes.

    Side aspects of this are which changes to do, and organizing efficient system maintenance work.

    For picking changes to work, I usually go with FIFO until some priority trumps that, such as reg compliance.

    But, if you do have many changes for one system, I always say to do them all in one scheduled maintenance project, so you only open the system up once, and test it once

  6. Let me state it a different way:

    Estimates are pointless unless they are used as decision drivers. The more critical the decision, the more attention should be placed on the accuracy of the estimate. If the decision may be re-visited, so should the estimate, and if it is more or less accurate than the basis for the last decision, an explanation should be included.

    Fair enough?