Probability that an adverse circumstance will occur, combined with its potential impact on the project.
Categories
By impact area
- Project risk
Affects schedule or resources. - Product risk
Affects quality or performance of the delivered software. - Business risk
Affects the developing or procuring organisation.
By source
- Technology risks
Risks from the software or hardware technologies used (e.g. new database technology with unknown performance characteristics). - People risks
Risks associated with team members (e.g. unavailability of specialist staff, lack of relevant skills). - Organizational risks
Risks from the organisational environment (e.g. funding restructures, management changes). - Requirements risks
Risks from changing or poorly understood requirements (e.g. customer-driven requirement changes late in the project). - Estimation risks
Risks from inaccurate estimates of resources or schedule (e.g. underestimating development time for complex components).
Risk indicator
Predefined metric used to detect early signs that a risk is materialising.
Examples:
- Staff turnover rate (people risk indicator)
- Number of unresolved requirements changes (requirements risk indicator)
- Ratio of actual to estimated effort per module (estimation risk indicator)
Risk Management
A proactive process of identifying, analyzing, and controlling risks before they become problems. Operates in 4 sequential stages that loop back continuously throughout the project.
Risk Identification
Identifying a list of risks that could threaten the project. Identification sources:
- team brainstorming activity
- individual manager experience
- historical data from similar projects
The by source categories serve as a checklist for systematic enumeration.
Risk Analysis
Assessing probability and seriousness of each identified risk. A probability scale and a consequence scale are each divided into 3, 4, or 5 discrete levels.
Typical probability levels: very low, low, moderate, high, very high.
Typical consequence levels: insignificant, tolerable, serious, catastrophic.
Each risk is entered into a risk register with:
- A description of the risk
- Probability level
- Consequence level
- An overall severity rating (often probability × consequence)
Risks above a severity threshold are flagged for active management. The output is a prioritized risk list ordered by severity, focusing planning effort on the highest-severity risks first.
Risk Planning
Developing strategies for each prioritized risk. Strategies split into 3 types:
- Avoidance strategies
Reduce the probability the risk arises (e.g. buy commercial off-the-shelf components to reduce technology risk). - Minimization strategies
Reduce the impact if the risk occurs (e.g. cross-train staff to minimize the impact of key-person absence). - Contingency plans
Predefined responses to execute if the risk materializes (e.g. have a backup supplier contracted in advance).
Each high-severity risk should have at least one strategy. Avoidance is preferred where cost-effective; contingency plans cover residual risk.
When an indicator exceeds a threshold, the corresponding contingency plan is activated.
Risk Monitoring
Regular assessment of each risk throughout the project. Performed at each project milestone or on a fixed schedule.
Each review checks:
- Whether risk probability has changed
- Whether consequences have changed
- Whether new risks have emerged
- Whether planned strategies are still adequate