Contingency is a critical component of any IT project. But calculating how much contingency is required can be a challenge for Project Managers (and other team members). This presentation reviews an approach that breaks down the underlying causes of estimation errors in IT projects and provides a framework for measuring the degree of contingency is required in any project.
5. Contingency Budgets
Dealing with unexpected costs.
● Standard Amount: Flat % of Overall Cost
● Risk Management: Calculating Probability by Cost of Impact
● Parameters: Standardized Estimates
● Reference Class Forecasting: Contingency Based on Overages
from Similar Projects
5
15. Separating Risk Types
Define Scope
Determine
Solutions
Estimate
Resources &
Timing
Set Budget
Project Development
15
16. Separating Risk Types
Define Scope
Determine
Solutions
Estimate
Resources &
Timing
Set Budget
Project Development
16
17. So Where Do Errors Happen?
Budgets require solution,
resourcing and timing
choices & estimates.
These are (usually) made in
collaboration with a
manager’s colleagues.
17
18. So Where Do Errors Happen?
And sometimes, these
decisions are difficult.
18
41. How to Embrace Risk and Budget Better
And then what…?
● Use to as basis to calculate probability/impact
as part of contingency calculation.
● Use to determine contingency amount based
on standard scale of Risk Score to $.
● Use as a ‘multiplier’ for the resource amounts
(i.e., ‘hard bake’ contingency into each
resource estimate).
● Develop mitigation/avoidance strategies for
any components with Risk Score above
certain amount.
Applying the Risk Score
41
42. How to Embrace Risk and Budget Better
This process is as much about avoiding the need for
contingency as calculating it.
42
The usual process that might include Discovery, on the road to a prelim budget (e.g., for an SOW or resource estimates)
Story about generating Padworx project budgets for app development: Tod Factor
Trusting that those giving the estimates are accurate, and that the estimate itself won’t be derailed by something.
This is why we have contingency
The classic ways of determining contingency in budgeting
What if we were to evaluate the underlying risk factors of specific projects, and calculate contingency based on those.
What if the estimation process itself provided inherently more accurate estimates?
And if that process allowed us to calculate more appropriate contingency levels (without having to calculate probability and impact)
Here is that project dev process again
First off, contingency is not about covering errors in the development or management of Scope.
But let’s take a quick review of how those issues are handled by best practice
While ‘Scope’ issues are risks that creep in on a project from the outside, Estimate and Solution Choice issues are ‘Embedded or Specific Risks’
Who has ever faced these kind of issues? Unfortunately, they often fall on the team delivering the product, since they exist within the agreed scope (hence the need for contingency)
Well, is there a set of mitigations we can apply (like we did for scope creation and management?)
Not really. Because you can’t manage yourself out of an estimation or solutioning error.
These are ‘foundational’ errors that no one intended and the best mitigation is to avoid them in the first place and/or provide contingency that will allow you to address them.
The good news is that there are 3 common underlying factors for most of these issues.
Any one of these factors can cause any one of the example issues
AND, these 3 factors can be viewed on a matrix that depicts low to high risk in any project
That can actually be quantified (though not as an actual measurement)
