Modus List 3: Our Five Estimate Pathologies

Business runs on estimates.  How long do you think that might take? we naively ask. Then when someone tells us how long they think something might take, we write that down and hold them to it.

Webster says the very word “estimate” means to roughly calculate or judge the value, number, quantity, or extent of something. “Roughly” … “judge.” We know that estimates are always wrong enough to be lottery-worthy when they are right.

Here are five estimate pathologies that cause us nothing but pain.

  1. Guarantism – The belief an estimate is actually correct.

When someone gives you a number, you believe it. Numbers are definite. They have credibility. When I plumber says, “This’ll probably cost ya about $600” your head immediately sets a price at $600. This is where we explore ideas of accountability. We believe that estimate is correct and we will now hold that plumber accountable even though he clearly said “probably” and “about.” Dollars, dates, and milestones become truths the moment they are uttered.

  1. Promisoriality – The belief that estimates are possible

When I make an estimate I fall prey to something called The Planning Fallacy. This tells us that we will almost always err in our estimates.  But when we give an estimate,  we feel we’ve given someone or word.  We feel it’s a promise.  That means we take ownership of it and become entrenched.  We believe our own estimate and begin to ignore warning signs that the estimate may,  in fact,  have been only an educated guess.

  1. Swami-itis – The belief that an estimates is a basis for sound decision making

Each project we undertake is an hypothesis.  We believe the actions included in our plan will result in the product we envision.  Further,  each product is envisioned to have an impact on the market.

The larger the project, the more guesses upon which you base your work.  We believe we can predict the future because the plans we are making sound plausible. In fact,  they are guess upon guess, assumption upon assumption.

  1. Craftosis – The assumption that estimates can be done better

We believe we will get better at our estimates.  That estimation is a skill.  This may be true,  our estimating skills can be honed.  However,  the planning fallacy and the realities of how we work put a cap on the accuracy we are able to attain.

Our accuracies are impacted by variation in the work and high margin work usually includes high variation.  When we plan or estimate at the task level,  the role of variation is so severe that simple changes in the weather or absence of a colleague due to the flu can derail an estimate and a project.

  1. Reality Blindness – The insistance that estimates are implementable

In business,  we create estimates and plans and begin work immediately,  rarely with the expectation that those plans will change.

In civil engineering there are different levels of estimates.  A planning level estimate is an estimate believed to have a high degree of unknowns which is therefore subject to high levels of variation and uncertainty.

An engineering level estimate actually comes with gradations of certainty. Construction plans will be provided and reviewed for 20% 30% … up to what is called a 100% submittal.

The 100% submittal is when work can begin. During actual construction the designs are further refined.  When the project is completed a while new set of drawings and documents are created to document what was actually built.  These are called “as-builts”. This is because even in a theorizing theoretically lower-variation environment like civil engineering we still don’t build to our estimates.

So tell me, what’s number 6?

Jim BensonModus List 3: Our Five Estimate Pathologies

12 Comments on “Modus List 3: Our Five Estimate Pathologies”

  1. Henrik


    Great post! That’s my experience as well!

    I have a though. Instead of a sixth point, how about suggestions on how to deal with these 5 pathologies? Without suggestions for improvement/change this is merely “whining”. Whining is all good (I know all about it 😉 But I think we must also move beyond.

    Any thoughts?

    Kind regards,

    1. Jim Benson


      Funny you should say that.

      Yesterday someone on the net wrote a scathing response to this post because they saw it as whining.

      But no one thought that about the previous two lists in this series. This list, like those lists, is just a list. The other two people praised as awesome lists. This one, however, seems to have struck a nerve with some.

      Simply by noticing these things exist, I’ve been told I didn’t go far enough.

      But … you know (as well as the other chap) that I’ve written four books on the subject and rarely whine about anything. So, I’m not really buying that this has anything to do with me or this list.

      I’m thinking that estimation itself is a highly emotional topic because we’ve all been burned by one or more of these problems. Otherwise I would have received the same comments about the previous two lists.

      Later in the series, perhaps I’ll do a “Five ways you can avoid estimate pathologies.” post.

  2. Neil Killick

    Hi Jim,

    Nice post, and one close to my heart 😉 (#NoEstimates and all that).

    Agree with all of these, and I think there is at least one more damaging pathology with estimates in our industry. I will call it:

    The belief that, when someone asks me for an estimate, I should simply go off and tell them “how long” rather than ask more questions about the actual information required and the underlying need.

    Much like when managers ask developers to write crappy code to be quicker, developers have choices in how they approach the situation, which can allow them to keep their professional integrity intact. To deliver high quality software that solves a customer problem we need to ask what the time/budget constraints are. What is the impact of taking 6 months versus 3 months (cost of delay)? Is there a firm market deadline, such as a customer commitment or a date after which we lose an opportunity? We also need to know if there are fixed requirements, and what exactly the outcome is we are looking to achieve.

    Without this information we cannot make good decisions when we are prioritising one thing over another, making trade-offs, trying to simplify things. We will also not be sure how best to measure progress. Forecasting how much we can get done by a deadline is very different from validating a customer problem or solution hypothesis. Or actual value realisation, such as increase in order value or conversion rates. A burn-up chart simply won’t cut it for these, and outcomes don’t necessarily neatly happen within time-boxes.

    We tend to shoot ourselves in the foot with estimates (I wrote a blog post about this). When asked for them, let us find out more information such that we can use creative problem solving to provide options. “In 3-4 months we could probably provide capability x, y. Z is possible but might take longer. We’ve done something similar before in that timeframe, but there’s more uncertainty/risk in this one. We’re going to run an experiment in week 1 to learn more, and keep you updated with progress as we go along”.

    1. Jim Benson

      Thanks man,

      That may be closest to the heart of the problem … as Mark and Glen note below. We are part of a system that is asking for the wrong thing and the people in that system have little choice but to comply.

      Hopefully by your work, Glen’s work, and my work (all coming from different angles) we can ask these questions enough to get people to slow down and actually examine the commitment they are about to make.


  3. Glen Alleman

    My post at suggests…and you’ve said it – noticing things exist does not go far enough. Difficulties in estimating exist across all domains, from small warehouse database projects, to multi-billion dollar flight systems for major weapons. But the processes of estimating is not fixed by “not estimating” as those in the No Estimates community would have us believe

    The key here is to understand the 5 symptoms of poor planning all have root causes. Each root cause has a corrective action. Each corrective action is hard to implement, hard to sustain, but for mission critical projects, manifestly important to apply.

    Most important when we hear estimating can’t be done, do your home work, look for thought leaders in estimating, read about estimating in all kinds of domains, and don’t believe any conjecture without first testing that concept in the broader realm of research, evidence based, peer reviewed, field validated concept. The notion that we can make decisions about the spending of other peoples money n the absence of estimating how much, when we’ll be done, and what we’ll be able to deliver is as Alistair suggests about #NoEstimates is a pile of self-contradictory statements.

    The open issue is when you start with the Planning Fallacy and don’t close the loop with Bent Flyvbjerg’s published solution – reference class forecasting – and the published solutions to anchoring and adjustment from Tversky and Kahneman original work and follow on corrective actions, it leads to the suggestion there are no solutions.

    1. Jim Benson

      Fair enough. But, again, this is list #3 in a series of lists. It’s not a post trying to provide better forecasting techniques. It was never meant to be one.

      I have witnessed all of these issues. There are many ways to compensate for things like the Planning Fallacy on a statistical or structural level.

      Every day, in every part of the world, poor sad people are being asked to guess and then held to those guesses. That’s a thing.

      There are people like you and Woody and myself who have come up with alternate ways to get around these pathologies … but the pathologies exist independent of the myriad of solutions out there.

      It’s like I wrote “people die from the flu” and you became angry because I didn’t say “get a flu shot.”

      This list .. also a thing. And, again, I ask you to read the first post in this series which specifically says that your objections are why I hate lists in the first place.

  4. Mark Stringer

    Hey Jim,

    I’m glad that you mentioned the Planning Fallacy. But it’s also worth mentioning why either refusing to make an estimate or making an estimate, that we know will be treated as a promise, makes us feel so bad. This is referred to by Robert Cialdini in his book “Influence – The Psychology of Persuasion” as “Commitment and Consistency” (

    I think of C&C as the electric cattle prod of project managment. Senior managers manoeuvre the development team into giving “estimates” which they then take as commitments. They use the breaking of these “commitments” as a way of manipulating and controlling the development team, but also as a way of avoiding responsibility themselves “What could I do? They lied to me! They told me the software would be ready by the 12th!”

    1. Jim Benson



      Social contracts in the office not only mean that people demand the off-the-cuff estimate, but that we want to give those estimates. We hate not being able to answer quickly or to appear to be saying no.

  5. Johannes Schartau

    Number 6 – The Distance Effect
    With increasing distance to the source of the estimate the perceived validity of the estimate increases exponentially. Bob’s rough coffee break guesstimate of “Yeah, we could probably get this done in one or two weeks, assuming nothing else pops up and Bill gets back tomorrow…” turns into “IT said they’ll have it done by Monday, so we should go ahead, start the marketing campaign and connect China to the network immediately.” Add extra validity if you’re a subsidiary and the estimate comes from the headquarters.

    1. Jim Benson

      I love it.

      In the end, almost all of these are, after all, communication breakdowns based on assumptions or misunderstandings. Estimates, being most often off the cuff, lend themselves to wild reinterpretations. (Even if there are ways to estimate better).

  6. Pingback: Herding Cats: Five Estimating Pathologies and Their Corrective Actions |

  7. Pingback: Évaluation d'un projet : les 5 erreurs à éviter

Leave a Reply

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