R – Evaluating software estimates: sure signs of unrealistic figures

estimationevaluationproject-management

Whilst answering “Dealing with awful estimates” posted by Ash I shared a few tips that I learned and personally use to spot weak estimates. But I am certain there must be many more!

What heuristics to use in the scenario when one needs to make a quick evaluation of software project estimate that has been compiled by a third-party (a colleague, a business partner or an external company)?

What are the obvious and not so obvious signs of weak software estimates that can be spotted without much detailed knowledge of task at hand?

Best Solution

  • A single person having done the estimates, rather than having used consensus based estimation (to fully understand the implied scope of requirements) such as Wideband Delphi.
    • Especially true if the person doing the estimation is not the person doing the implementation!! - I once worked on a project estimated by someone else as 60 days before any requirements had even been given. Lets just say I was not a happy bunny
  • No time for documentation.
  • No time for ramp-up (in terms of learning, and team size).
  • No list of risks, and their impact to the timescale.
  • No buffer for the unexpected - in terms of late breaking requirements, and risks.
Related Question