Lesson 1 — Risk Identification and Response Planning¶
At a glance
- Module: 08 — Risk Management
- Level: Intermediate
- Estimated time: 45 minutes
- Example project: the hospital appointment system
Learning objectives¶
By the end of this lesson you should be able to:
- Distinguish a risk from an issue, and state a risk in terms of cause, event, and impact.
- Use structured techniques to identify risks rather than waiting for inspiration.
- Assess probability and impact, and rank risks by exposure.
- Select and justify a response strategy for a threat and for an opportunity.
- Maintain a risk register with owners, triggers, and fallback plans.
Prerequisites¶
Introduction¶
Projects are attempts to create something that does not yet exist, by people who have not done exactly this before, under constraints that will change. Uncertainty is therefore not a defect in a project — it is a defining feature of one.
Risk management is the discipline of deciding in advance how to deal with that uncertainty. Its output is not a document; it is a set of decisions that only have to be made once, calmly, rather than repeatedly, in a hurry.
1. Risk and issue¶
| Term | Definition | When it is managed |
|---|---|---|
| Risk | An uncertain event that, if it occurs, affects objectives | Before it happens |
| Issue | Something that has already happened and needs resolution | Now |
A risk that occurs becomes an issue. The difference matters because they are managed by different processes and different people, and because a register full of issues is a register that has stopped looking forward.
2. Stating a risk properly¶
A risk statement has three parts. Omitting any of them makes the risk unmanageable.
Because ‹cause›, there is a risk that ‹event›, which would result in ‹impact›.
"Because the integration with the hospital's patient-record system is specified by a third party, there is a risk that its interface changes during our build, which would result in us rebuilding the integration and losing roughly a week."
That statement names an owner, a plausibility, and something you can act on. "Integration risk" — the common alternative — names none of them.
3. Identification techniques¶
- Assumption analysis — every assumption in your plan is a risk if it turns out false. This is usually the highest-yield technique, and it costs nothing because the assumptions are already written down.
- Checklists — standard categories prompt recall: requirements, technology, people, suppliers, regulation, dependencies.
- Pre-mortem — assume the project has already failed and write the reasons. It reliably surfaces risks that a forward-looking discussion suppresses, because it legitimises criticism.
- Expert interviews and brainstorming — best run with people from outside the team, who do not share its blind spots.
- Historical records — retrospective notes and the previous risk register.
Label your example data
When you use a case to generate risks, say clearly whether the risks are real or constructed for teaching. Invented risks presented as findings from a real project are a form of fabrication, and they teach students to trust unreferenced claims.
4. Assessing and ranking¶
Each risk gets a probability and an impact, and their product is its exposure.
| Risk | Probability | Impact | Exposure | Rank |
|---|---|---|---|---|
| Interface changes during build | Medium (3) | 1 week lost (3) | 9 | 1 |
| Clinic staff unavailable for review | High (4) | 2 weeks lost (4) | 16 | — |
| Hosting approval delayed | Low (2) | 3 weeks lost (4) | 8 | 2 |
Scale definitions must be written down and shared, or the scores are meaningless. A probability of "3" means nothing until the team agrees that 3 means "roughly one project in three".
Ranking is not the same as prioritisation. A risk with a low score but catastrophic, irreversible impact — patient data exposed, for instance — should be treated as high priority regardless of its probability. Expected value arithmetic is a poor tool for irreversible harm.
5. Response strategies¶
For threats:
| Strategy | Meaning | Example |
|---|---|---|
| Avoid | Remove the cause | Drop the risky integration from scope |
| Transfer | Move the consequences to another party | Contract a supplier who accepts the risk |
| Mitigate | Reduce probability or impact | Prototype the interface early |
| Accept | Do nothing but hold contingency | Small, cheap-to-fix risks |
For opportunities — which are risks with upside, and are routinely ignored:
| Strategy | Meaning | Example |
|---|---|---|
| Exploit | Make it happen | Assign your best developer to the reusable component |
| Share | Partner to gain the benefit | Joint development with another department |
| Enhance | Increase the chance or size | Fund training that makes an earlier reuse realistic |
| Accept | Take it if it comes | Note it and move on |
Each response plan needs three things: an owner who is accountable, a trigger or early warning indicator that tells you the risk is materialising, and a fallback plan for what you do if the response fails.
Key terms¶
| Term | Meaning |
|---|---|
| Risk | An uncertain event that would affect objectives if it occurred |
| Issue | A problem that has already occurred |
| Exposure | Probability multiplied by impact, used for ranking |
| Trigger | An early warning indicator that a risk is materialising |
| Contingency plan | The planned action if a risk occurs |
| Fallback plan | The action if the contingency plan fails |
| Residual risk | Risk remaining after the response is applied |
| Secondary risk | A new risk created by the response itself |
Worked example¶
Task: build a risk register for the illustrative hospital appointment system. Risks are invented for teaching, not findings from a real project.
Step 1 — Analyse assumptions. The project's assumptions include: the patient-record interface is stable; clinic staff are available for fortnightly reviews; hosting is approved before launch. Each becomes a risk.
Step 2 — Identify risks from several sources.
| # | Risk statement | Prob. | Impact | Exposure |
|---|---|---|---|---|
| R1 | Because the patient-record interface is owned by a third party, its specification may change mid-build, forcing rework | 3 | 3 | 9 |
| R2 | Because clinic staff are also delivering patient care, their availability for reviews may fall below plan, delaying sign-off | 4 | 4 | 16 |
| R3 | Because hosting approval involves a separate governance process, it may be granted late, blocking launch | 2 | 4 | 8 |
| R4 | Because the appointment rules are only partly documented, requirements may be discovered late | 4 | 3 | 12 |
| R5 | Because only one team member knows the reporting stack, their absence would stall reporting work | 2 | 4 | 8 |
Step 3 — Rank, then override honestly. By exposure the order is R2 (16), R4 (12), R1 (9), then R3 and R5 (8). R3 is promoted above R1 by judgement: a late hosting approval is an external, absolute blocker, whereas R1 has a workaround.
Step 4 — Plan a response for each.
| # | Strategy | Response | Owner | Trigger |
|---|---|---|---|---|
| R1 | Mitigate | Build a thin interface prototype in week 2 to surface mismatch early | Dev lead | Third party misses a spec-agreement milestone |
| R2 | Mitigate | Book review slots a month ahead; appoint a deputy from the clinic | Project manager | Review attendance below half for two consecutive sessions |
| R3 | Avoid | Start the hosting approval process in week 1, before it is needed | Project manager | Approval not granted by week 8 |
| R4 | Mitigate | Run a rules-discovery workshop with two clinic staff in week 3 | Analyst | Fewer than five rules confirmed per workshop |
| R5 | Transfer (knowledge) | Pair the specialist with a second developer; document the setup | Dev lead | Any unplanned absence of the specialist |
Step 5 — Note the secondary risk. Pairing for R5 costs the specialist's time and may slow reporting work. That is a secondary risk, and it goes in the register.
Step 6 — Confirm residual risk. Suppose the responses are applied. R1's residual exposure falls to 1 × 3 = 3. R2's falls to 2 × 4 = 8. R3 remains at 2 × 4 = 8 — an external process cannot be fully avoided by planning. Recording residual risk is what tells you how much contingency to hold.
Step 7 — Feed the cost model. The contingency in Module 07 was the cost of these responses. Risk management and budgeting are the same activity described in two vocabularies.
Common misconceptions¶
“Risk management is a document”
A register nobody reads is worse than no register, because it creates the appearance of control. The output is decisions: an early prototype, a booked review, a started approval.
“Low-probability risks can be ignored”
Expected-value ranking hides irreversibility. A one-in-fifty chance of exposing patient records is not a small risk; it is a different kind of risk, and must be treated as such.
“Responding to a risk removes it”
Responses usually leave residual risk and often create secondary risk. Both belong in the register.
Practical activity¶
Build a risk register. Choose one example project and:
- List the plan's assumptions, and treat each as a potential risk.
- Write five risk statements in the cause–event–impact form.
- Score probability and impact against scales you define explicitly, and rank by exposure.
- Choose a response strategy for each, with an owner and a trigger.
- Identify one secondary risk created by your own response and one residual risk you must accept.
What "good" looks like: risk statements with all three parts, scales that are defined rather than assumed, an owner for every risk, and at least one honest admission that a response creates a new risk.
Self-assessment¶
- Rewrite as a proper risk statement: "Scope creep is a risk."
- Why is assumption analysis a high-yield identification technique?
- Give one threat where acceptance is the correct strategy and explain why.
-
What is the difference between a contingency plan and a fallback plan?
-
Apply it — hospital appointment system. Two things worry you. One engineer is the only person who understands the legacy scheduling database; she has not taken leave in eighteen months and a competitor is recruiting from the department. Separately, the outpatient department plans an unrelated change to the clinic system in the same month as your pilot.
Hint: A strong answer states each as a cause-event-impact risk and names the response strategy with its owner.
Show answers
- Something like: "Because the sponsor has authority to add requirements without a change process, there is a risk that scope grows faster than the team delivers, which would result in the launch date slipping with no corresponding increase in budget." Note that this version also implies the response — establish a change process.
- Because the assumptions are already written in the plan, so no new discovery work is needed; and because a false assumption is by definition something that would damage the project — if it were harmless it would not need to be assumed.
- A small, cheap, unlikely risk, or a risk where any response would cost more than the impact — for instance, a minor UI preference that may change. It must still be recorded, with contingency, so its occurrence is not a surprise.
- A contingency plan is what you will do if the risk occurs. A fallback plan is what you will do if the contingency plan does not work. Having both means the second decision is also made calmly, in advance.
- Risk 1 — knowledge concentration. Because only one engineer understands the legacy schema (cause), if she leaves or is unavailable (event), the integration stalls and the pilot slips by an unknown number of weeks (impact). Response: mitigate — document the schema and interfaces, cross-train a second engineer, and use her for knowledge transfer rather than keeping her on the critical path; accept the residual that a departure still costs time. Risk 2 — conflicting change window. Because the department has scheduled an unrelated clinic-system change in your pilot month (cause), if it consumes operational attention or alters the scheduling interface (event), the pilot loses both support and stability (impact). Response: avoid or coordinate — move your pilot, or have the two changes deliberately combined into one window. Name an owner and a review date for both. One ranking caveat worth stating: exposure (probability × impact) is a guide, and irreversibility can override it — here the loss of the only integration engineer is slow to recover from, which argues for acting on it even though its probability is uncertain.
Summary¶
- A risk is uncertain and future-facing; an issue has already happened.
- Risk statements combine cause, event, and impact, and are usually generated from assumptions, checklists, pre-mortems, and history.
- Exposure (probability × impact) ranks risks, but irreversibility overrides ranking.
- Threats are avoided, transferred, mitigated, or accepted; opportunities are exploited, shared, enhanced, or accepted.
- Every risk needs an owner, a trigger, and a fallback. Responses leave residual risk and create secondary risk.
Further learning¶
- Module 09 — Quality Management covers quality risks, which are often misclassified as schedule risks.
- A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute — risk management.
- Waltzing with Bears: Managing Risk on Software Projects, Tom DeMarco and Timothy Lister.
- ISO 31000, Risk management — Guidelines, International Organization for Standardization.
Next¶
You have completed Module 08. Continue to Module 09 — Quality Management.