Quantifying software project risk and having a systematic way of accounting for it in software estimates helps firms determine how much contingency (or management reserve) is needed to protect against factors like scope growth, lower than anticipated productivity, or technical challenges that keep teams from executing project plans as originally intended.  When risk mitigation is an explicit part of the software estimate, we can set reasonable client and management expectations and negotiate practical project plans with a higher likelihood of success.

Dealing with Uncertainty

At the time most software estimates are performed, detailed design is incomplete and major decisions about how the system will be designed, coded, tested, and delivered have not yet been made.  Faced with imperfect information, estimators must supply educated guesses – hopefully based on sound requirements and performance data from completed projects - about the final delivered size, productivity, team size, and schedule.  Because the inputs to the estimate are uncertain, the final outcomes are also uncertain.

When we estimate that a project will most likely take 6 months and 8 full-time staff to execute, we really should say, “Based on our analysis and past performance data, we expect the project to take 6 months and use 8 people, but the schedule could vary by as much as 15% and the budget by up to 20%.” But all too often, clients and management expect “single point” estimates based more on optimism than careful risk analysis.