Karmona Pragmatic Blog

Don't get overconfident… Tiny minds also think alike

Karmona Pragmatic Blog

Underestimation is Underestimated

April 19th, 2010 by Moti Karmona | מוטי קרמונה · 8 Comments

Underestimation is Underestimated (a.k.a. Overestimation is Overestimated)

Sometimes it seems like we have an underestimation gene embedded really deep in our cognition but for some “obvious” reason (e.g. underestimation! :) most manager will rather “fight” overestimation and *not* underestimation.

Disclaimer: I have originally estimated this post will take ~33 min but it took me ~240% more time… (this is why I prefer to tweet lately ;)

Six annoying facts about our (/homo sapiens) planning or estimation “skills”:

  • We are basically optimistic and have strong desire to please
  • We tend to have incomplete recall of previous experience
  • We tend to have focus bias when estimating e.g. estimating only the coding phase estimations which is only ~14-37% of the required work
  • We tend to postpone what we can a.k.a. “The Student Syndrome”  (Eliyahu M. Goldratt, Critical Chain)
  • “It always takes longer than you expect, even when you take into account Hofstadter’s Law (Douglas Hofstadter, Godel, Escher, Bach: An Eternal Golden Braid)
  • We tend to underestimate task completion times – a.k.a. The planning fallacy

Overestimation is Overestimated

“The developers say that this project will take 6 months… I think there’s some padding in their estimates and some fat that can be squeezed out of them…we also need to instill a sense of urgency in the development team… so I’m going to insist on a 3-month schedule. I don’t really believe the project can be completed in 3 months, but that’s what I’m going to present to the developers. If I’m right, the developers might deliver in 4 or 5 months. Worst case, the developers will deliver in the 6 months they originally estimated” (Does this ring *any* bell???)

Four reasons on managers tendency to “fight” overestimations:

  • Underestimation (see above :) | “The feature estimation seems bloated” | “Isn’t it 20 min work?” | “Just add another index to the %$^&ing table?” | “It is only one more button…”
  • Unreasonable time constraint | “We need this feature yesterday” | “Nothing is impossible for the man who doesn’t have to do it himself” (A. H. Weiler)
  • True belief that Parkinson’s “Law” is really a law – “Work expands so as to fill the time available for its completion”
  • “The Student Syndrome”  (see above)

So… if feature estimation seems bloated, managers and other project stakeholders fear that Parkinson’s Law and the Student Syndrome would kick in and therefore consciously squeeze the estimates to try to control it (a.k.a. “The Parkinson’s Squeeze”) and when we squeeze where it isn’t needed or was squeezed already, it immediately lead to… UNDERESTIMATION (!!!)

Underestimation is Underestimated

Underestimation creates numerous problems – some obvious, some not so obvious.

  • Reduced effectiveness of project plans – Low estimates undermine effective planning by feeding bad assumptions into plans for specific activities. They can cause planning errors in the team size, such as planning to use a team that’s smaller than it should be. They can undermine the ability to coordinate among groups – if the groups aren’t ready when they said they would be, other groups won’t be able to integrate with their work. If the estimation errors caused the plans to be off by only 5% or 10%, those errors wouldn’t cause any significant problems but numerous studies have found that software estimates are often inaccurate by 100% or more (see above). When the planning assumptions are wrong by this magnitude, the average project’s plans are based on assumptions that are so far off that the plans are virtually useless.
  • Statistically reduced chance of on-time completion – Developers typically estimate 20% to 30% lower than their actual effort. Merely using their normal estimates makes the project plans optimistic. Reducing their estimates even further simply reduces the chances of on-time completion even more.
  • Poor technical foundation leads to worse-than-nominal results. A low estimate can cause you to spend too little time on upstream activities such as requirements and design. If you don’t put enough focus on requirements and design, you’ll get to redo your requirements and redo your design later in the project – at greater cost than if you’d done those activities well in the first place. This ultimately makes your project take much longer than it would have taken with an accurate estimate.
  • Destructive late-project dynamics make the project worse than nominal Once a project gets into “late” status, project teams engage in numerous activities that they don’t need to engage in during an “on-time” project… below are some examples when the important characteristic of each of these activities is that they don’t need to occur at all when a project is meeting its goals, these extra activities drain time away from productive work on the project and make it take longer than it would if it were estimated and planned accurately
    • More status meetings with upper management to discuss how to get the project back on track
    • Frequent re-estimation, late in the project, to determine just when the project will be completed.
    • Apologizing to key customers for missing delivery dates (including attending meetings with those customers).
    • Preparing interim releases to support customer demos, trade shows, and so on. If the software were ready on time, the software itself could be used, and no interim release would be necessary.
    • More discussions about which requirements absolutely must be added because the project has been underway so long.
    • Fixing problems arising from quick and dirty workarounds that were implemented earlier in response to the schedule pressure.

Tip of the day
Never intentionally underestimate. The penalty for underestimation is more severe than the penalty for overestimation. Address concerns about overestimation through control, tracking and *mentoring* but not by bias.

****************************************

More related posts (a.k.a. people who read this post also read these posts)

Tags: Management · Planning · Project Management · Psychology · Software Management

8 responses so far ↓

  • 1  Tzvika // Apr 19, 2010 at 8:24 am

    I like Joel’s approach: http://www.joelonsoftware.com/items/2007/10/26.html

    Not surprisingly he aligns with you on not undercutting estimates… you dev managers are all the same :-)

  • 2  Shlomi cohen // Apr 21, 2010 at 1:28 pm

    Really elaborating article moti,
    i want to add another long term aspect, when people will have spare time as a result of “wrong” overestimation they will also learn more , will have the time to pick their heads and see what other teams are doing , learning more technologies etc, something they would never do if they are in pressure.
    you mention about the requirement and design , to do it right the first time so we would not waist time on this later in project – do i hear the words mini-waterfall ? :-)

  • 3  Moti Karmona | מוטי קרמונה // Apr 21, 2010 at 4:51 pm

    @Tzvika, thank you very much for the comparison! :)

    @ Shlomi,

    (1) I agree although this (e.g. learning) is something I prefer to manage/lead/control and not leave for chance.

    (2) No way…! :) * requirement/design/testing/qa != waterfall*

    Software development is iterative process (including design phase) and I don’t think anyone can really “do it right the first time” but design is a mandatory phase (no matter what methodology you use) to make sure “visible” design mistakes are not being made.

  • 4  Shlomi cohen // Apr 21, 2010 at 5:19 pm

    let me clarify :-)
    i’m not suggesting working in waterfall but ..
    when you want to have quality requirement and design sessions to save some future investment then you might spend the whole sprint or even more on those.
    when the requirements + design are not in the same sprint as the implementation = imho you are getting closer to “mini waterfall”

    BTW – i wrote this message 3 times cause of errors and i only estimated 1 minute reply :-)

  • 5  Vivek Sagi // Jun 30, 2010 at 4:00 pm

    Good post Moti and as expected from a engineering head…. :-)

    Speaking from the other side.. of product management.. most times overestimation is the starting point for a discussion on scope because engineers (good ones atleast) tend to over design and over engineer even prototypes when some times speed to market is important.

  • 6  Ronen Narkis // Jul 7, 2010 at 1:32 am

    This post made me think about what is common to the stock market and software delivery estimations, they both seem predictable at first but might turn into chaos due to the large number of factors that influence them.

    Also like the stock market intuition and experience can make the difference.

  • 7  Oren Ellenbogen // Jul 23, 2010 at 5:01 pm

    Great post Moti, really well thought and well written. Indeed, underestimation causes drastic pains due to organization time versus personal time. If one is late, dependencies might be broken, shifting pressure (and late schedule) to other parts of the organization.

    I feel that overestimation is also underestimated. Overestimation is why startup fails, why big companies moving too slow. Pressure is good, as long as it’s healthy and carefully watched. I would hate working for a company that does everything extremely well but takes 2 years to release simple functionality.

    At the end of the day, it’s really matter of paying attention. Avoid wasting estimation time when not needed (far away roadmap), breaking features by end-to-end tasks instead of “UI”/”Business”/”Data Access”, pricing tasks by low granularity to allow confidence building and shifting tasks, considering organization time over personal time (add “design time”, “design review”, “code review”, “bug fixing buffer” etc).

    We should focus on understanding where are we going and what we want to achieve, create a path to allow confidence.

    Trying to avoid overestimation or underestimation is futile. It’s the stuff behind it that’s interesting, like you mentioned (mentoring)

  • 8  Moti Karmona | מוטי קרמונה // Jul 30, 2010 at 10:50 pm

    All is true…

Leave a Comment

Allowed tags <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

mortarless-expediency