Part VIII

PART VIII: Risk & Mitigation

Every recommendation involves uncertainty. The goal of a strong case solution is not to pretend that risk can be eliminated. It is to demonstrate that your team understands what could prevent the recommendation from succeeding and how the organisation should respond. Risk should therefore be considered throughout the case-solving process—not added as a final slide just before the conclusion. The goal is to answer: What could materially change our decision, prevent successful execution, or reduce the value we expect to create—and what are we going to do about it?

Chapter 12: Don’t Hide the Risk

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

One of the easiest ways to weaken a case solution is to pretend that nothing will go wrong. Every strategy involves uncertainty. Customers may not respond as expected. Costs may be higher than estimated. Competitors may react. Employees may resist. Technology may fail. Regulations may change. Implementation may take longer than planned. Acknowledging these possibilities does not weaken your recommendation. Ignoring them does. A strong recommendation is not one without risk. It is one where the risks are understood, evaluated, and managed.

Risk Belongs Throughout the Case

Teams often treat risk as something to discuss after they have already made the recommendation. That is too late. Risk can affect:

how you define the problem;
which alternatives are feasible;
how alternatives are evaluated;
which alternative you recommend;
how the recommendation is implemented;
how much the strategy costs;
and how success should be measured.

Risk should therefore be integrated into the decision process:

ANALYZE → IDENTIFY RISK → EVALUATE ALTERNATIVES → RECOMMEND → MITIGATE → IMPLEMENT → MONITOR

Risk is part of strategy, not an appendix to it.

Focus on Strategic Risk

A case solution does not need a list of everything that could go wrong. Focus on the risks that could materially affect the success of the recommendation. Ask: What would have to go wrong for this recommendation to fail? Potential categories include:

Market Risk

Demand is lower than expected.
Customer preferences change.
Market growth slows.
Customer adoption is weak.

Competitive Risk

Competitors respond aggressively.
A new entrant appears.
Competitors reduce prices.
Substitutes become more attractive.

Financial Risk

Costs exceed estimates.
Revenue develops more slowly than expected.
Financing becomes more expensive.
Cash flow becomes constrained.

Operational Risk

Capacity is insufficient.
Suppliers cannot deliver.
Quality deteriorates.
Implementation takes longer than expected.

People Risk

Employees resist the change.
Critical skills are unavailable.
Key employees leave.
Training is ineffective.

Technology Risk

Systems do not integrate.
Development is delayed.
Cybersecurity problems emerge.
Technology does not perform as expected.

Regulatory or Legal Risk

Regulations change.
Approvals are delayed.
Compliance costs increase.
Legal challenges emerge.

Reputational Risk

Customers react negatively.
Stakeholders oppose the strategy.
Implementation damages the brand.

The categories help you think. But remember the principle from Chapter 7: The framework is not the analysis. Your job is to identify the risks that actually matter in this case.

Prioritise the Risks

Not all risks deserve equal attention. A useful starting point is:

RISK PRIORITY = PROBABILITY × IMPACT

Ask two questions:

Probability: How likely is this risk to occur?
Impact: If it occurs, how serious would the consequences be?

This creates a simple risk matrix:

	Low Impact	Medium Impact	High Impact
High Probability	Monitor	Manage	Priority
Medium Probability	Monitor	Manage	Priority
Low Probability	Accept	Monitor	Contingency

The exact labels matter less than the thinking. You are trying to determine: Which risks deserve management attention?

Don't Waste Time on Trivial Risks

Teams sometimes create long risk lists because they believe more risks demonstrate more thorough analysis. They don't. A slide containing twelve generic risks may be less useful than one containing the three risks that could actually derail the strategy. Prioritise. Ask: If we could actively manage only three risks, which three would matter most? Those probably deserve attention in your presentation.

Move From Risk to Mitigation

Identifying the risk is only the beginning. For every major risk, ask: What can the organisation actually do about it?

The basic structure is:

RISK → MITIGATION

For example:

Risk: Customer adoption is slower than expected. --> Mitigation: Pilot the offering with selected customers before committing to full rollout.

That is already stronger than: "Monitor customer adoption." But you can go further.

Make Mitigation Executable

A strong mitigation should connect directly to implementation. For example:

Risk: Customer adoption is slower than expected.
Mitigation: Launch a limited pilot before full rollout.
Implementation: Pilot with selected customers during Months 1–3.
Owner: Marketing + Operations.
KPI: Customer adoption and retention.
Decision Trigger: Proceed to full rollout only if adoption reaches the agreed threshold.

Now risk management has become part of the strategy.

The Risk-to-Action Chain

A useful structure is:

RISK --> MITIGATION --> ACTION --> OWNER --> KPI --> TRIGGER / CONTINGENCY

For example:

Risk	Mitigation	Owner	KPI	Response
Low customer adoption	Pilot before rollout	Marketing	Adoption rate	Modify offer if below target
Cost overruns	Stage-gate investment	Finance	Cost variance	Pause expansion if threshold exceeded
Employee resistance	Training and engagement	HR	Adoption/training	Additional support
Capacity constraints	Phased expansion	Operations	Capacity utilization	Add capacity before next phase

This is much stronger than simply listing risks. It shows management what to do about them.

Mitigation Is Not “Monitor”

One of the most common weak mitigations is: "We will monitor the risk." Monitoring may be necessary. But monitoring alone does not reduce the probability or impact of the risk. A real mitigation should do something. For example:

Weak
- Risk: Costs exceed expectations.
  Mitigation: Monitor costs.
Stronger
- Risk: Costs exceed expectations.
  Mitigation: Establish monthly budget reviews and a 10% contingency reserve, with additional spending requiring approval once the variance exceeds the established threshold.

The second response changes what the organisation will actually do.

Some Risks Should Change the Recommendation

This is particularly important. Risk analysis is not simply about protecting a recommendation you have already chosen. Sometimes the risk analysis should make you change the recommendation. Suppose Alternative A has the highest expected financial return. But it also requires:

capabilities the organisation does not possess;
substantial debt;
regulatory approval;
and three years before positive cash flow.

Alternative B may generate a somewhat lower expected return but have:

significantly lower execution risk;
faster cash generation;
better capability fit;
and greater strategic flexibility.

The "highest return" option may not be the best option. That is why risk belongs in alternative evaluation.

Test the Assumptions Behind the Risk

Many strategic risks originate in assumptions. Your recommendation might assume:

customers will adopt;
prices can be increased;
costs will remain stable;
market growth will continue;
employees can be hired;
financing will be available;
technology can be implemented on schedule.

Ask: Which assumptions, if wrong, would most seriously damage the recommendation? These are the assumptions worth testing. This connects risk analysis directly to sensitivity and scenario analysis. Instead of asking: "What happens if sales are 10% lower?" ask: "At what point does the recommendation stop making sense?" That is a much more powerful strategic question.

Build Contingencies

Mitigation attempts to reduce risk. A contingency answers a different question: What will we do if the risk actually happens? For example:

Risk: Customer adoption is lower than expected.
Mitigation: Pilot before full launch.
Contingency: If adoption remains below 15% after three months, modify the value proposition and delay expansion.
This creates a decision rule: IF this happens → THEN we do this.

These rules make the implementation plan more adaptive.

Consider the Risk of Success

Risk does not only mean failure. Sometimes the strategy works better than expected. Ask: What happens if demand exceeds our expectations? Could the organisation face:

insufficient capacity;
inventory shortages;
staffing shortages;
working capital pressure;
technology overload;
declining service quality;
supplier constraints?

A recommendation that creates enormous demand but destroys the customer experience may not be successful for long. Good risk analysis considers both:

Downside Risk: What happens if performance is worse than expected?
Upside Risk: What happens if performance is better than expected?

The implementation plan should be able to respond to both.

Risk Should Connect to the Financials

Financial analysis provides another opportunity to test risk. Instead of presenting only: Base Case ROI = 32%. consider:

Scenario	Revenue Growth	Cost	ROI
Downside	3%	$6.0M	8%
Base	8%	$5.5M	32%
Upside	12%	$5.2M	51%

The important question is not simply whether the numbers change. Ask: Does our decision change? If the recommendation remains attractive across reasonable scenarios, you have demonstrated robustness. If it fails under a relatively small change in assumptions, management needs to know that.

Risk Should Connect to Implementation

Your risk analysis and implementation plan should tell the same story. If your risk slide says:

Risk: Employees may resist the change.
- Your implementation plan should include something like: Employee engagement and training before rollout.
If your risk slide says: Risk: Customer adoption may be weak.
- Your implementation should include: Pilot → Measure → Decision Gate → Scale
If your risk slide says: Risk: Demand could exceed capacity.
- Your implementation should include: Capacity trigger → Additional resources → Expansion

This creates consistency across the solution.

The Risk Rule

If the mitigation doesn't appear somewhere in the implementation plan, it probably isn't a real mitigation. Risk and implementation should not exist on separate islands. They should reinforce one another.

The Risk Test

Before finalising your risk analysis, ask:

MATERIALITY: Could this risk materially affect the recommendation?
PROBABILITY: How likely is it?
IMPACT: How serious would the consequences be?
MITIGATION: Can we reduce the probability or impact?
ACTION: What specifically will the organisation do?
OWNER: Who is responsible?
KPI: What will tell us the risk is emerging?
TRIGGER: At what point should management act?
CONTINGENCY: What happens if the risk actually occurs?
IMPLEMENTATION: Does the mitigation appear in our implementation plan?

If you cannot answer these questions for your most important risks, the risk analysis needs more work.

Discover Your Mad Skills Principle

Don't hide risk. Design for it.

Strong teams do not pretend their recommendation is guaranteed to succeed. They demonstrate that they understand where it could fail, how they will know, and what the organisation should do about it.

The Bottom Line

Risk should strengthen your recommendation, not undermine it. The goal is not to produce a long list of everything that could go wrong. The goal is to identify the risks that could change the decision or derail execution and build responses into the strategy. Think:

RISK → MITIGATION → ACTION → OWNER → KPI → TRIGGER → CONTINGENCY

When risk analysis is integrated with your alternatives, financial analysis, recommendation, and implementation plan, it demonstrates something judges value enormously: Your team has not simply imagined how the strategy succeeds. You have thought through what happens when reality doesn't follow the plan.