Chapter 25: Risk and Mitigation

Chapter 25: Risk and Mitigation - Making the Recommendation Resilient

Video: Risks & Mitigations That Actually Strengthen Your Recommendation: Don't Hide Them - Integrate Them

Learning Objectives

By the end of this chapter, you should be able to:

• identify the risks that could materially prevent a recommendation from succeeding;

• distinguish risks from assumptions, causes, impacts, and current issues;

• write clear and specific risk statements;

• assess risks using Probability and Impact;

• recognise low-probability risks with severe consequences;

• prioritise the risks requiring management attention;

• select an appropriate risk response;

• distinguish prevention from contingency planning;

• create practical mitigations, triggers, and fallback actions;

• assign ownership and accountability;

• integrate mitigations into the implementation roadmap and budget;

• communicate risk honestly without undermining the recommendation;

• assess the residual risk remaining after mitigation.

Why This Matters

Many teams treat risk as a final slide containing three generic statements:

• customers may not adopt the solution;

• costs may be higher than expected;

• competitors may respond.

They add "monitor closely" beside each one and move on. That is not risk management. A risk matters because it could prevent the recommendation from achieving its intended objective. Managing that risk requires more than acknowledging its existence. The team must determine:

• what could happen;

• why it could happen;

• how likely it is;

• how serious the consequences would be;

• what can be done before it occurs;

• how the organisation will know it is emerging;

• what the organisation will do if it occurs;

• who is responsible;

• where the response appears in implementation.

Risk should never be an afterthought. Important risks should influence the recommendation, financial analysis, implementation sequence, decision gates, resources, and metrics.

Discover Your MAD Skills Principle

Don’t pretend your strategy has no risks. Show that you understand them, have prioritised them, and know how to respond.

Acknowledging risk doesn't weaken a recommendation. Ignoring an obvious risk makes the team appear unprepared. Identifying a risk and showing how to manage it demonstrates judgment.

Risk Cannot Be Eliminated.

Every meaningful strategic choice contains uncertainty. A strategy without risk may also offer little opportunity. The objective is not to remove every possible risk. It is to:

• identify the risks that matter;

• reduce avoidable exposure;

• prepare for adverse outcomes;

• preserve the ability to adapt;

• determine whether the remaining risk is acceptable.

The question is not: "How do we make the strategy risk-free?" It is: "How do we make the strategy resilient enough to pursue responsibly?"

Deciphering Case Characteristics

Different cases create different risk priorities.

Growth Case

Potential risks include:

• demand below expectations;

• excessive customer-acquisition costs;

• capacity constraints;

• declining margins;

• overextension.

Market-Entry Case

Potential risks include:

• weak local demand;

• regulatory barriers;

• cultural differences;

• competitor retaliation;

• partner dependency;

• exchange-rate exposure.

Innovation Case

Potential risks include:

• technology failure;

• low customer adoption;

• long development periods;

• intellectual-property challenges;

• rapid imitation;

• uncertain unit economics.

Turnaround Case

Potential risks include:

• insufficient liquidity;

• employee departures;

• customer loss;

• operational disruption;

• delayed savings;

• stakeholder resistance.

Digital Transformation Case

Potential risks include:

• integration failure;

• poor data quality;

• cybersecurity;

• low employee adoption;

• implementation delays;

• vendor dependency.

Sustainability Case

Potential risks include:

• regulatory change;

• technology uncertainty;

• reputational damage;

• supplier non-compliance;

• measurement challenges;

• greenwashing concerns.

Public-Sector or Nonprofit Case

Potential risks include:

• stakeholder opposition;

• funding instability;

• political change;

• inequitable outcomes;

• implementation capacity;

• loss of public trust.

Risk analysis should reflect the case, not a standard list.

Risk, Assumption, Issue, Cause, and Impact

These terms are related but different.

• Assumption
  • Something believed to be true for planning purposes.
  • Customers will be willing to purchase six times per year.
  • An assumption becomes a source of risk when uncertainty around it could materially change the result.
• Risk
  • A possible future event or condition that could affect the strategy.
  • Customer purchase frequency may be lower than expected.
• Issue
  • A problem that already exists.
  • Current customers purchase only 4 times per year.
  • An issue requires action now. A risk requires preparation for what may happen.
• Cause
  • The condition that may produce the risk event.
  • The offering may not provide enough variety to encourage repeat purchases.
  • Impact
  • The consequence if the risk occurs.
  • Revenue and contribution margin would fall, extending the payback period.

Strong risk analysis keeps these elements separate.

Write a Complete Risk Statement

"Customer adoption" is not a complete risk statement. Use this structure: Because of [CAUSE], there is a risk that [EVENT], resulting in [IMPACT]. For example: Because the company has limited brand awareness in the new region, there is a risk that customer adoption will fall below the required threshold, resulting in lower revenue and delayed investment payback. This structure clarifies:

• why the risk may occur;

• what may happen;

• why it matters.

It also makes the mitigation easier to design.

What Is a Strategic Risk?

A strategic risk is a possible event or condition that could materially prevent the recommendation from achieving its objective. Common categories include:

Market and Customer Risk

• weak demand;

• low adoption;

• poor retention;

• price sensitivity;

• changing preferences.

Competitive Risk

• aggressive pricing;

• imitation;

• new market entry;

• substitute products;

• channel conflict.

Financial Risk

• cost overruns;

• inadequate funding;

• margin pressure;

• cash-flow shortfalls;

• exchange-rate changes.

Operational Risk

• process failure;

• capacity constraints;

• quality problems;

• delivery delays;

• supply disruption.

Technology and Data Risk

• system failure;

• integration problems;

• cybersecurity breaches;

• poor data quality;

• vendor dependency.

People and Organisational Risk

• skills shortages;

• employee resistance;

• leadership misalignment;

• turnover;

• weak accountability.

Legal and Regulatory Risk

• delayed approvals;

• new regulation;

• non-compliance;

• privacy violations;

• contractual disputes.

Stakeholder and Reputational Risk

• community opposition;

• partner conflict;

• customer distrust;

• public criticism;

• ethical concerns.

Categories help generate risks, but the final analysis should focus on the few risks that could materially alter the recommendation.

Risk Is Not the Same as Impact

Teams often say: "A major risk is declining profit." Declining profit is usually an impact. The risk event may be:

• customer adoption falls below forecast;

• costs exceed budget;

• launch is delayed;

• price competition intensifies.

The resulting Impact may be:

• reduced profit;

• lower cash flow;

• longer payback;

• failure to achieve the strategic objective.

Identifying the actual event makes mitigation possible.

Probability and Impact

Assess each risk using two dimensions.

• Probability: How likely is the risk to occur?
• Impact: How serious would the consequences be if it occurred?

A simple scale can be used:

Rating	Probability	Impact
1	Very unlikely	Minimal disruption
2	Unlikely	Manageable Impact
3	Possible	Material impact requiring management attention
4	Likely	Serious Impact on implementation or results
5	Very likely	Threatens the viability of the strategy

A simple priority score can be calculated as Risk Priority = Probability × Impact. However, the number should support, not replace judgment. A score of 12 is not automatically more important than a score of 10. A low-probability event with catastrophic safety, legal, or reputational consequences may require immediate attention regardless of the mathematical score.

Consider Speed and Detectability

For particularly important risks, two additional questions may be useful.

• Speed
  • How quickly would the consequences appear?
  • A cybersecurity breach may create immediate damage. Weak customer retention may emerge more slowly.
• Detectability
  • How easily can the organisation identify the risk before significant damage occurs?
  • A risk that is difficult to detect may require stronger controls or earlier indicators.

You don't need to score every dimension. Use them when they materially affect the response.

Inherent and Residual Risk

• Inherent Risk
  • The level of exposure before mitigation.
• Residual Risk
  • The remaining exposure after mitigation is implemented.

For example:

• Inherent risk: High Probability and high Impact.

• Mitigation: Conduct a limited pilot, test the value proposition, and stage investment.

• Residual risk: Medium Probability and medium Impact.

Mitigation rarely removes the risk completely. The organisation must determine whether the residual risk is acceptable.

Prioritise Ruthlessly

A case solution doesn't need a list of 15 risks. Focus on approximately three to five risks that could:

• prevent the strategy from achieving its objective;

• materially damage financial performance;

• delay a critical implementation milestone;

• harm priority stakeholders;

• create legal, safety, ethical, or reputational consequences;

• cause management to reconsider the recommendation.

Ask: "Could this risk materially change our decision or prevent execution?" If not, it may not deserve space in the main presentation.

Use the Failure Test

Imagine that the strategy failed two years from now. Ask:

• What most likely caused the failure?

• Which assumption proved false?

• Which stakeholder resisted?

• Which capability was missing?

• Which cost was underestimated?

• Which dependency broke down?

• Which competitor response did we overlook?

This is sometimes called a pre-mortem. It helps teams identify risks before becoming overly committed to the recommendation.

Select the Appropriate Risk Response

There are four broad responses.

Avoid

Change the strategy so the risk no longer exists. Example: Don't enter a market where regulatory approval is unlikely. Avoidance may reduce risk, but it may also sacrifice the opportunity.

Reduce

Take action to lower the Probability or Impact. Examples:

• run a pilot;

• conduct technical testing;

• train employees;

• use multiple suppliers;

• stage investment.

Transfer or Share

Move or share some exposure through:

• insurance;

• contracts;

• partnerships;

• guarantees;

• outsourcing.

The risk is rarely transferred completely. The organisation may still face reputational or operational consequences.

Accept

Recognise the risk and proceed without additional prevention because:

• the exposure is low;

• mitigation costs more than the likely damage;

• the risk is unavoidable;

• the opportunity justifies the exposure.

Accepted risks may still require monitoring and contingency planning.

Prevention and Contingency Are Different

A strong risk response may contain two types of action.

• Preventive Mitigation
  • Reduces the Probability that the risk will occur. Example: Test the product with the priority customer segment before full launch.
• Contingency Plan
  • Reduces the Impact after the risk occurs. Example: If adoption remains below the threshold, revise the value proposition, shift acquisition spending, and delay expansion.

Prevention asks: "How can we reduce the chance of this happening?" Contingency asks: "What will we do if it happens anyway?" Both may be required.

"Monitor" Is Not a Complete Mitigation

Monitoring is important, but by itself it doesn't reduce risk.

• Weak: "Monitor customer adoption."
• Stronger: "Launch a six-month pilot, review adoption weekly, and delay expansion if active customers remain below 1,200."

The stronger response contains:

• an action;

• a metric;

• a review period;

• a threshold;

• a decision.

The Complete Risk Response

For each major risk, define:

1. Risk statement: What could happen, why, and what is the consequence?

2. Probability: How likely is it?

3. Impact: How serious would it be?

4. Response: Avoid, reduce, transfer, or accept?

5. Preventive mitigation: What will reduce the Probability?

6. Early-warning indicator: How will the organisation know the risk is emerging?

7. Trigger: What threshold requires action?

8. Contingency: What happens if the risk occurs?

9. Owner: Who is accountable?

10. Residual risk: What exposure remains?

This transforms risk analysis into management action.

Leading Indicators and Triggers

An early-warning indicator provides evidence that a risk is emerging.

Examples include:

Risk	Early-Warning Indicator
Weak adoption	Low trial registrations or conversion
Customer churn	Declining repeat purchase rate
Cost overrun	Monthly spending above budget
Schedule delay	Critical milestones repeatedly missed
Talent shortage	Extended vacancy periods
Technology failure	High error rates during testing
Supplier disruption	Declining delivery reliability
Stakeholder resistance	Low participation or rising complaints

A trigger identifies the point at which management must act. For example, if customer acquisition cost exceeds $120 for two consecutive months, pause expansion and reallocate spending to the two best-performing channels. A trigger converts monitoring into a decision rule.

Assign a Risk Owner

Every major risk needs one accountable owner. The owner should:

• monitor the early-warning indicator;

• ensure preventive actions are completed;

• activate the contingency plan when required;

• report changes in exposure;

• coordinate with affected workstreams.

Possible owners include:

• CFO for financial exposure;

• COO for operational risk;

• Chief Technology Officer for technology risk;

• HR leader for talent and adoption risk;

• VP Marketing for customer-adoption risk;

• Legal counsel for regulatory risk;

• Implementation lead for schedule and dependency risk.

The owner is not necessarily the person performing every mitigation activity. The owner is accountable for ensuring the risk is managed.

Build Mitigation Into Implementation

Risk mitigation should appear in the implementation roadmap. For example:

Risk	Mitigation	Roadmap Integration
Low customer adoption	Pilot with priority segment	Launch and Learn phase
Technology failure	Complete integration and load testing	Build and Prepare phase
Cost overrun	Stage funding through decision gates	Governance and Finance workstream
Employee resistance	Engage employees and provide role-based training	People and Capability workstream
Supplier disruption	Qualify a backup supplier	Operations workstream

If the mitigation doesn't appear in:

• the roadmap;

• the budget;

• ownership;

• KPIs;

• decision gates;

it may not actually be part of the solution.

Include the Cost of Mitigation

Risk responses may require:

• additional testing;

• insurance;

• contingency funding;

• employee training;

• backup suppliers;

• legal support;

• cybersecurity controls;

• extra implementation time.

These costs should be reflected in the financial case. A recommendation cannot claim both:

• the protection created by the mitigation; and

• the lower cost that would result from omitting it.

Ensure that the risk plan, implementation roadmap, and financial model remain consistent.

Use Risk to Improve the Strategy

Risk analysis may change the recommendation. For example:

• Original Recommendation
  • Launch nationally.
• Risk Insight
  • Customer adoption and unit economics remain highly uncertain.
• Revised Recommendation
  • Launch a regional pilot and expand only after meeting customer and financial thresholds.

Or:

• Original Recommendation
  • Build the technology internally.
• Risk Insight
  • The organisation lacks the required skills and faces a long development period.
• Revised Recommendation
  • Partner with a proven provider while building selected internal capabilities.

Risk analysis should not merely defend the existing strategy. It should improve it.

Interconnected Risks

Risks don't always occur independently.

• For example: Technology Delay → Launch Delay → Higher Implementation Cost → Reduced Cash Runway → Lower Stakeholder Confidence
• Or: Employee Resistance → Low System Adoption → Limited Productivity Improvement x→ Financial Benefits Not Realised.

Understanding these connections can reveal which risk is the true leverage point. Mitigating an early risk in the chain may prevent several downstream consequences.

Risk Appetite and Tolerance

Different organisations have different capacities and willingness to accept risk. Consider:

• financial strength;

• regulatory obligations;

• mission;

• stakeholder expectations;

• leadership preferences;

• reversibility of the decision;

• seriousness of potential harm.

A well-funded technology company may be willing to accept more experimental risk than a cash-constrained nonprofit. A healthcare organisation may have almost no tolerance for patient safety risks. The recommendation should align with the organisation's capacity to absorb failure.

Worked Example: Partnership-Led Regional Entry

The meal-kit company plans to enter Western Canada through a partnership-led pilot. The team identifies four priority risks.

Priority Risk	Probability	Impact	Preventive Mitigation	Trigger and Contingency	Owner
Customer adoption falls below the level required for profitable expansion	Medium	High	Test the offering with the priority segment and launch a six-month pilot	If active customers remain below 1,200, delay expansion and revise the value proposition and channel mix	VP Marketing
Partnership performance fails to meet service requirements	Medium	High	Establish service-level agreements, shared governance, and performance reporting.	If on-time fulfilment falls below 95% for two consecutive months, activate the corrective action plan and assess backup distribution.	COO
Technology integration delays the launch	Medium	Medium	Complete staged integration testing before launch approval	If critical testing milestones are missed by more than four weeks, delay launch and use a limited manual process where feasible	Technology Lead
Customer acquisition cost exceeds the financial threshold	Medium	High	Test channels in small campaigns and shift spending towards high-performing sources	If acquisition cost exceeds the approved limit for two months, pause spending and redesign the acquisition plan	VP Marketing and CFO

Residual Risk

After mitigation:

• customer adoption risk remains medium because demand cannot be known with certainty before launch;

• partner risk falls from high to medium because contracts and service-level controls reduce exposure;

• technology risk falls from medium to low after staged testing;

• acquisition-cost risk remains medium and will be managed through channel testing and decision gates.

Strategic Effect

The risks support the use of:

• a regional pilot;

• staged investment;

• clear service agreements;

• defined expansion thresholds;

• monthly performance reviews.

Risk management is now embedded in the strategy and roadmap.

Build a Practical Risk Register

A concise risk register may include:

Risk	Probability	Impact	Mitigation	Indicator/Trigger	Contingency	Owner	Residual Risk

The main presentation may show only the three most important risks. For Q&A, prepare a more detailed register.

Visualising Risk

A risk slide may be useful, but risk should not be isolated from the rest of the solution. Useful visual approaches include:

• Probability–Impact Matrix
  • Shows which risks require priority attention.
• Risk–Mitigation Table
  • Shows the connection between each risk and management response.
• Roadmap Integration
  • Places mitigations and decision gates directly on the implementation timeline.
• Assumption–Threshold–Action Table
  • Shows:

  • what must be true;

  • how it will be measured;

  • what action follows if it is not true.

Choose the visual that best explains how the strategy becomes more resilient.

Winning the Room

A strong risk explanation might sound like: "The greatest risk is customer adoption. Because the company has limited brand awareness in the region, demand may fall below the level required for profitable expansion. We reduce this exposure through a six-month pilot focused on the priority segment. The VP Marketing will monitor active customers, acquisition cost, and retention. Expansion will proceed only if the pilot exceeds 1,200 active customers and maintains the required unit economics. If those thresholds are missed, the company will revise the offering and acquisition channels before committing additional capital." This explanation communicates:

• the cause;

• the risk event;

• the Impact;

• the mitigation;

• the owner;

• the indicator;

• the trigger;

• the contingency.

Communicate Risk Without Undermining the Recommendation

Avoid language that sounds either careless or alarmist.

• Weak: "There really aren't many risks."
• Also weak: "The strategy could fail in many different ways."
• Stronger: "The recommendation carries three material risks. Each has been prioritised, assigned an owner, and addressed through the pilot design, staged investment, and performance gates."

Confidence comes from preparedness, not denial.

Coach's Lens

The strongest mitigation often appears in the design of the recommendation itself.

• Uncertain demand leads to a pilot.

• Technology uncertainty leads to staged testing.

• Cost uncertainty leads to milestone-based funding.

• Stakeholder resistance leads to early engagement.

• Supplier risk leads to dual sourcing.

• Capability gaps lead to partnership or targeted hiring.

I often ask teams: "Where does this mitigation appear in your implementation plan?" If the answer is "nowhere," the mitigation is probably only a promise. Risk management should change what the organisation actually does.

Common Mistakes

• List Every Possible Risk: Focus on risks that could materially alter or derail the strategy.
• Using One-Word Risks: "Competition," “technology," and "adoption" are categories, not complete risk statements.
• Confusing Causes, Risks, and Impacts: Explain what could happen, why, and the consequence. 
• Confusing Probability and Impact: A risk may be unlikely but severe.
• Treating the Score as the Decision: \A probability–impact score supports prioritisation but doesn't replace judgment.
• Ignoring Catastrophic Risks: Safety, legal, ethical, or reputational risks may require attention even when Probability is low.
• Generic Mitigations: "Monitor closely" is not enough.
• No Contingency: Explain what happens if prevention fails.
• No Trigger: Define when management must act.
• No Owner: Someone must be accountable.
• Mitigations Missing From Implementation: If the mitigation is not scheduled, funded, and owned, it may not happen.
• Mitigation Costs Missing From the Financial Model: Risk reduction requires resources.
• Claiming the Risk Has Been Eliminated: Most mitigations leave residual exposure.
• Treating Risks as Independent: One risk can create several downstream problems.
• Hiding Risk: Judges are likely to identify obvious vulnerabilities. Address them first.
• Overemphasising Risk: Don't allow the risk section to make a sound recommendation appear irresponsible. Focus on priority risks and effective responses.
• Isolating Risk on the Final Slide: A dedicated slide may be useful, but risk should also influence the strategy, roadmap, financial case, and decision gates.

MAD Skills Drill

Take the recommendation and implementation roadmap developed in Chapters 22 and 24.

Part One: Conduct a Pre-Mortem

Imagine the recommendation failed. Write five reasons why.

Part Two: Identify the Top Risks

Reduce the list to the three risks most likely to derail the strategy. For each, identify:

• cause;

• risk event;

• impact.

Part Three: Write the Risk Statements

Use: Because of [CAUSE], there is a risk that [EVENT], resulting in [IMPACT].

Part Four: Prioritise

Assess:

• probability;

• impact;

• speed where relevant;

• detectability where relevant.

Part Five: Select the Response

Choose:

• avoid;

• reduce;

• transfer or share;

• accept.

Explain why.

Part Six: Build the Mitigation

For each risk, identify:

• preventive action;

• early-warning indicator;

• trigger;

• contingency;

• owner;

• required budget or resource.

Part Seven: Estimate Residual Risk

After mitigation, reassess:

• probability;

• impact;

• acceptability.

Part Eight: Integrate

Show where each mitigation appears in:

• the implementation roadmap;

• the budget;

• the KPI system;

• the decision gates.

If the answer is "nowhere," revise the plan.

Part Nine: Present

Explain the most important risk and response in 30 seconds. Your explanation should include:

• what could happen;

• why it matters;

• how it will be prevented;

• what will trigger action;

• what happens if it occurs.

Reflection Questions

1. Which risk could most easily derail the recommendation?

2. Did you identify the risk event or only its Impact?

3. What assumption creates the greatest exposure?

4. Which risk is unlikely but potentially catastrophic?

5. What preventive action reduces the Probability?

6. What contingency reduces the Impact?

7. Which indicator provides the earliest warning?

8. What threshold triggers action?

9. Who owns each major risk?

10. Where does each mitigation appear in implementation?

11. Are mitigation costs included in the financial case?

12. What residual risk remains?

13. Is the residual risk acceptable?

14. Did the risk analysis strengthen or change the recommendation?

Chapter Summary

Strong teams don't pretend uncertainty can be eliminated. They demonstrate that risk has been understood and managed. A disciplined risk process moves through: Cause → Risk Event → Impact → Probability & Severity → Priority → Response → Mitigation → Indicator → Trigger → Contingency → Owner → Residual Risk. Risk analysis makes the recommendation more honest. Mitigation makes it more resilient. The strongest risk responses are not promises on a final slide. They are visible in:

• the strategic design;

• the implementation roadmap;

• the financial model;

• the budget;

• the KPIs;

• the decision gates.

Key Takeaways

✓ Focus on risks that could materially prevent the strategy from achieving its objective.

✓ Distinguish assumptions, risks, current issues, causes, and impacts.

✓ Write complete risk statements that explain cause, event, and consequence.

✓ Assess Probability and Impact separately.

✓ Consider low-probability risks with catastrophic consequences.

✓ Use risk scores to support, not replace, judgment.

✓ Select an appropriate response: avoid, reduce, transfer or share, or accept.

✓ Distinguish preventive mitigation from contingency planning.

✓ "Monitor closely" is not a sufficient mitigation.

✓ Define early-warning indicators and action triggers.

✓ Assign an accountable owner to every major risk.

✓ Integrate mitigation into the roadmap, budget, KPIs, and decision gates.

✓ Assess the residual risk remaining after mitigation.

✓ Use risk analysis to improve the recommendation, not merely defend it.

✓ Communicate risk confidently and honestly.

Looking Ahead

Risk indicators tell us what could go wrong. A complete management system must also show whether the strategy is producing the intended results. The next chapter asks how the organisation will measure progress, determine whether the strategy is working, and decide when to adjust course. That brings us to KPIs, performance measurement, and strategic control.