Software Risk Management
Practice · Chapter 2
Overview
Section titled “Overview”Risks are potential problems, and software design/development carries many. Organizations differ in risk tolerance but should all have a risk-management plan. Architects assist project managers in managing risk; unmanaged risk leads to cost/time overruns, rework, operational failures, and possibly total project failure.
1. Identify risks
Section titled “1. Identify risks”The team should document potential risks. An architect’s knowledge and experience can surface risks that stakeholders, PMs, and other team members miss.
| Risk type | Examples |
|---|---|
| Functional | Incorrect requirements; lack of end-user/BA participation; conflicting business goals |
| Technical | Complexity; project size; unfamiliar languages/tools/frameworks; vendor/subcontractor dependencies |
| Personnel | Team lacking experience/skills; inability to staff; productivity issues |
| Financial | Insufficient funding; hard-to-meet ROI constraints |
| Legal | Government regulations; changing legal requirements; contractual changes |
| Management | Lack of experience/skill; incorrect planning; poor communication; organizational issues |
2. Evaluate risks
Section titled “2. Evaluate risks”Assess each risk’s potential impact and probability of occurring. Risks that are both high-impact and high-likelihood are the most critical to a project.
3. Handle risks — four techniques
Section titled “3. Handle risks — four techniques”| Technique | What it does | Example |
|---|---|---|
| Risk avoidance | Change the project to eliminate the risk entirely | Use a familiar technology instead of an unfamiliar one (if it still meets needs). Note: not all risks can be avoided, and avoiding one may create others; taking risk is sometimes needed to seize an opportunity. |
| Transfer | Move the risk to another party | Build contract penalties so a subcontractor bears the risk of late/low-quality deliverables. |
| Mitigation | Reduce the likelihood the risk occurs | Assign a mentor to a new, less-experienced team member to lessen delay/quality risk. |
| Acceptance | Accept the risk and its consequences | Accept not being first to market in exchange for shipping a better, unrushed product. |
Key caution: actions taken to mitigate or transfer a risk can introduce their own risks (e.g., rushing to finish sooner raises the chance of missed requirements or lower quality) — factor this into the analysis.
Related
Section titled “Related”- Security-specific risk analysis: threat modeling.
Citations
Section titled “Citations”- Software Architect’s Handbook (Packt, 2018), Ch.2 “Software risk management”, pp. 122-127.