Purpose

Every project has risks. The question is whether you manage them or they manage you.

Inexperienced teams treat risks as surprises — problems that appear without warning and demand immediate attention. They spend their time reacting, firefighting, explaining to stakeholders why something they should have seen coming has now derailed the plan.

Experienced teams treat risks as inventory — a known list of things that might go wrong, tracked and tended like any other project asset. When a risk materialises, they are not surprised. They anticipated it, prepared for it and often prevented it entirely.

The difference is not luck or intuition. It is discipline. Risk management is the practice of asking three questions early and often: What might go wrong? What can we do to prevent it? What do we do if we cannot prevent it?

This sounds simple. In practice, it separates projects that deliver from projects that drift into crisis.

---

The Cost of Unmanaged Risk

Projects without deliberate risk management follow a predictable pattern.

Early on, the team is focused on building. Risks exist, but no one is tracking them. Some risks are obvious — everyone knows the timeline is aggressive, the dependency on another team is fragile, the requirements are not fully locked down — but these concerns live in hallway conversations and private worries, not in any shared view.

Then something goes wrong. The dependency slips. The scope expands. A key person leaves. The team scrambles. Stakeholders are surprised and frustrated. The project loses credibility, and the team loses time they cannot afford.

The painful part: most of these problems were foreseeable. Someone on the team saw them coming. But without a process for surfacing risks, assessing them and deciding what to do, that foresight never translated into action.

Unmanaged risks do not stay risks. They become issues — and issues are far more expensive to address than risks that were handled early.

---

The Risk Management Discipline

Risk management is not bureaucracy. It is a lightweight discipline that makes projects more predictable and teams more credible.

The discipline has six components:

1. Risk Identification

Start by asking: what could go wrong?

This is a brainstorming exercise, best done with the team rather than alone. Think through different dimensions of the project:

• People: Key person leaves, stakeholder becomes difficult, team lacks a critical skill
• Dependencies: Another team misses a deadline, a vendor fails to deliver, an API changes unexpectedly
• Scope: Requirements expand, assumptions prove wrong, edge cases multiply
• Technology: System fails, performance does not meet expectations, integration proves harder than expected
• External: Regulatory changes, competitive moves, market shifts

The goal is not to identify every possible risk. It is to surface the risks that are both plausible and consequential — the ones that could actually derail the project if they materialised.

2. Probability and Impact

For each risk, assess two things:

• Probability: How likely is this to happen? (Low / Medium / High, or a numeric scale)
• Impact: If it happens, how bad is it? (Low / Medium / High, or a numeric scale)

Neither assessment needs to be precise. The point is to create a shared view of which risks matter most.

Multiply probability by impact to get exposure — a simple score that helps you prioritise. A high-probability, high-impact risk demands immediate attention. A low-probability, low-impact risk can be noted and monitored without active management.

3. The Working List

You cannot actively manage every risk. Teams that try end up managing none of them well.

Instead, focus on a working list — typically the top ten risks by exposure. These are the risks you will actively track, mitigate and prepare contingencies for. Other risks remain on the radar but do not receive the same level of attention.

The size of your working list depends on team capacity, project complexity and organisational risk tolerance. Ten is a common default. The important thing is to be explicit about which risks you are managing and which you are accepting.

4. Mitigation Plans

For each risk on your working list, develop a mitigation plan: what will you do to reduce the probability or impact of this risk?

Mitigation is about prevention. It is the work you do now to make the risk less likely to occur or less damaging if it does.

Examples:

• Risk: Key team member might leave. Mitigation: Cross-train another team member on their responsibilities. Document critical knowledge.
• Risk: Dependency on another team might slip. Mitigation: Establish weekly check-ins with that team. Get early warning signals into your process.
• Risk: Scope might expand beyond capacity. Mitigation: Lock requirements by a specific date. Establish a change control process with stakeholder sign-off.
• Risk: Production system might fail under load. Mitigation: Conduct load testing before launch. Establish performance baselines.

Some mitigations are simple. Others require significant effort. The investment should match the exposure — high-exposure risks warrant more aggressive mitigation.

5. Contingency Plans

Mitigation reduces risk. It does not eliminate it. For each risk on your working list, also develop a contingency plan: what will you do if this risk materialises despite your mitigation efforts?

Contingency is about response. It is the plan you execute when prevention fails.

Examples:

• Risk: Key team member leaves. Contingency: Engage a contractor with relevant skills. Extend timeline for affected workstreams.
• Risk: Dependency slips. Contingency: Implement a workaround using internal resources. Descope features that require the dependency.
• Risk: Scope expands beyond capacity. Contingency: Negotiate timeline extension. Identify features to defer to a later phase.
• Risk: Production system fails. Contingency: Activate incident response process. Roll back to previous stable version.

Having a contingency plan does not mean you expect to use it. It means you are not starting from zero if the worst happens.

6. Triggers

One of the hardest parts of risk management is knowing when to act.

Consider a common scenario: you depend on another team to deliver a component. They promised it by the first of the month. The first passes, then a week, then two. Each day you hope tomorrow will be different. Each day you delay implementing your contingency plan, you have less time to execute it.

This is where triggers matter.

A trigger is a predetermined condition that activates your contingency plan. It removes the ambiguity and the temptation to wait just one more day.

Examples:

• "If the component is not delivered within five business days of the committed date, we activate the contingency plan."
• "If the customer has not signed off on requirements by March 15, we escalate to the executive sponsor."
• "If load testing shows performance below threshold, we delay launch by two weeks."

Triggers are especially important for dependencies. Work with the teams you depend on to agree on triggers together. This makes escalation a matter of process, not personal conflict. When the trigger fires, everyone knows what to expect.

---

Keeping Risk Management Alive

Risk management is not a one-time exercise. Risks evolve. New risks emerge. Probabilities and impacts shift as the project progresses.

Build risk review into your regular cadence:

• Weekly or biweekly: Review the working list. Have probabilities or impacts changed? Have any risks materialised? Are mitigations on track? Are there new risks to add?
• At major milestones: Reassess the full risk inventory. The risks that matter at project start are different from the risks that matter at launch.
• With stakeholders: Share your risk management approach with sponsors and key stakeholders. They will appreciate the proactive stance — and they often surface risks you had not considered.

Risk management should be visible, not hidden. A team that openly tracks and discusses risks builds credibility. A team that hides risks until they explode loses trust.

---

Dependencies Deserve Special Attention

Dependencies are among the most common and most consequential project risks. When your success requires another team to deliver, you have limited control and significant exposure.

Treat every significant dependency as a managed risk:

• Identify it explicitly. Do not assume the dependency will work out. Name it, track it, assess its probability of slipping.
• Establish communication. Regular check-ins with the team you depend on. Early warning when things are off track.
• Develop mitigation. Can you reduce the dependency? Build an abstraction layer? Start work in parallel?
• Develop contingency. If they do not deliver, what is your fallback? Workaround, descope, delay?
• Agree on triggers. Work with your counterpart to establish what happens if the commitment is missed. Make it a shared plan, not an adversarial escalation.

The teams that manage dependencies well are the teams that acknowledge the risk upfront and plan for it together. The teams that struggle are the ones who assume everything will work out and are caught off guard when it does not.

---

Signs Proactive Risk Management Is Working

• The team maintains a visible, prioritised list of risks
• Risks are discussed regularly, not just when something goes wrong
• Stakeholders know the top risks and the plans to address them
• When risks materialise, there is a plan ready — not a scramble
• Dependencies have explicit owners, communication cadences and triggers
• The team's credibility increases because they deliver what they promise

---

Signs Proactive Risk Management Is Broken

• Risks live in people's heads, not in a shared view
• Risk discussions happen only after something has gone wrong
• The team is frequently surprised by problems that were foreseeable
• Dependencies slip without warning or escalation
• Stakeholders lose confidence because issues keep appearing unexpectedly
• Mitigation is reactive — addressing problems only after they materialise
• No one can articulate the top risks facing the project

---

Summary

Risk management is the discipline of asking what might go wrong before it does — and preparing to prevent it or respond to it.

The practice is straightforward: identify risks, assess their probability and impact, focus on the ones that matter most, develop mitigation and contingency plans and establish triggers for when to act. Review regularly. Communicate openly.

The difference between projects that deliver and projects that drift into crisis is often not the risks themselves — it is whether the team saw them coming and did something about it. Unmanaged risks become issues. Issues consume time, erode credibility and derail plans.

Proactive risk management is not overhead. It is one of the highest-leverage investments a project team can make. The time spent anticipating problems is always less than the time spent recovering from them.