In one line: Risk is uncertainty that matters to your objectives. Manage it by identifying it early, rating its likelihood and consequence, choosing a response, and tracking it until it is retired.
Core idea
Every project carries uncertainty about technology, schedule, cost, suppliers, requirements and people. Risk management makes that uncertainty explicit, so it can be worked deliberately instead of discovered late. It is one of the core technical management processes in the systems engineering handbooks [1], and it connects directly to failure analysis at the design level (see Failure Mode and Effects Analysis).
How it works
The four questions the program asks of every organization:
| Question | Practice |
|---|---|
| What is risk? | a potential future event that would affect objectives, characterized by its likelihood and consequence (and, in many programs, its timeframe) |
| How do you identify it? | design reviews, brainstorming, checklists, lessons learned, FMEA, assumption analysis, supplier and test data, and asking the people closest to the work |
| How do you quantify and assess it? | rate likelihood and consequence, often on a 5 × 5 matrix, so that each risk lands in a green, yellow or red zone; for big decisions, use quantitative analysis such as Monte Carlo schedule or cost models |
| How do you manage and mitigate it? | choose a response, assign an owner, set trigger dates, track in a risk register, and review regularly |
Response options:
- avoid: change the plan so the risk can’t occur
- mitigate: reduce the likelihood or consequence
- transfer: to a supplier, insurer or contract
- accept: deliberately, with a contingency, and with management informed
In practice
In many engineering groups, risks are surfaced at design reviews: unknowns are called out, mitigations proposed, and risks without a mitigation are explicitly acknowledged by management. That is a sound starting point. It works better with a living register and clear owners than with slides that disappear after the review. Two cultural points matter as much as the method:
- Risk reporting must be safe, or the register fills with risks nobody is worried about while the real ones go unspoken (see Psychological Safety).
- The burden of proof belongs on safety, not on danger. The Challenger Launch Decision is the case study in what happens when it is reversed.
Questions to ask yourself
- What are the top three risks on my project, who owns each, and when will each be retired?
- Which risk are we accepting implicitly, without anyone having decided to?
- Would someone on my team feel safe raising a risk that threatened the schedule?
Connections
- Design-level tool: Failure Mode and Effects Analysis. Process home: Systems Engineering Process.
- Related controls: Engineering Change Control. When risk becomes reality: Crisis Leadership.
- Culture: Psychological Safety. Case: Challenger Launch Decision.
- Capabilities exercised: Decision Making, Courage, Communicating and Advocacy.
Sources
- NASA (2007) Systems Engineering Handbook [1]
- Course assignment on risk procedures; no public source.