Risk refinement, RMMM, and the risk information sheet

The thinking move: a risk you cannot act on is not yet refined enough

A risk written early in a project is usually a worry with a name — "the vendor might be late". You cannot mitigate a worry. You cannot monitor it either, because nothing about it says what to watch. Refinement is the step that turns a worry into something with handles: you decompose the general statement into a small set of more detailed risks, each of which is individually easier to mitigate, monitor and manage. This is the single most under-taught move in the chapter and it is the one that separates a risk register that changes behaviour from one that gets filed.

The standard vehicle is the condition–transition–consequence form: given that [condition], then there is concern that possibly [consequence]. Writing the risk this way forces you to state the condition that makes it possible, which is usually where the mitigation lives. You then break the condition into subconditions, each naming one specific mechanism. The consequence normally stays the same across all of them — you have not changed what could go wrong, you have located why, which is precisely what you can act on.

The three Ms are three different moments

RMMM stands for risk mitigation, monitoring and management, and the reason all three exist is that they happen at three different times relative to the risk materialising.

Mitigation happens before. It is problem avoidance: an action taken now that reduces the probability of the risk, or its impact if it lands anyway. For a staff-turnover risk that means finding out why people are leaving and fixing what you can before the project starts, then designing for continuity regardless — dispersing knowledge, defining work-product standards so an artefact stands on its own, reviewing every piece of work so more than one person understands it, and assigning a backup for every critical specialist.

Monitoring happens during. It is a tracking activity with three jobs: to check whether the predicted risks are in fact occurring, to check that the mitigation steps are actually being applied, and to collect information that improves the next project's risk analysis. It has to name indicators — observable things that move when the risk is materialising — because "keep an eye on it" is not monitoring.

Management happens after. It assumes mitigation has failed and the risk is now real, and it executes the prepared contingency. It also needs a trigger: the stated condition at which the contingency fires, decided in advance and in writing, because deciding it in the moment is exactly the reactive behaviour this whole apparatus exists to prevent.

RMMM is not free

Every one of those steps costs money and time. Assigning a backup for each critical specialist means paying two people to know one thing. Building a simulator means building software that ships to nobody. So risk management includes an economic judgement: compare the cost of risk aversion against the risk exposure it removes. If mitigating a risk costs more than the exposure it eliminates, do not mitigate it — monitor it and prepare a contingency instead. That comparison is the sentence that turns a risk plan from a wish list into engineering.

The RMMM plan and the risk information sheet

The RMMM plan documents all the work done in risk analysis. It can be a section of the project plan, or a standalone document; many teams do neither and instead maintain one risk information sheet per risk, held in a shared database so the sheets can be searched, sorted and reused between projects. The sheet's fields are the contract: risk ID, date, probability, impact, description, refinement or context, mitigation and monitoring, management, contingency and trigger, current status, and who raised it and who owns it. Whatever the format, the plan is revisited at every increment boundary — probabilities move, some risks expire, and new ones arrive.

Worked example — R-01 refined and sheeted

BorrowBox's top risk was "the locker vendor's SDK slips six weeks", at 60 per cent and impact 1. In condition–transition–consequence form it became: given that the door-open path cannot be exercised without a vendor SDK whose last two releases each slipped by more than a month, then there is concern that possibly the SDK arrives after week 6, leaving the driver, wire-up and field-trial tasks — the entire critical path — with no float.

Refining the condition produced three subconditions, and each one suggested a different action. First, the vendor publishes no dated roadmap, so our only signal is their public forum — which makes forum cadence a monitorable indicator. Second, the beta SDK channel is outside our support contract, so problems found there have no committed response time — which is a contractual fix, not a technical one. Third, the purchase order contains no delivery date and therefore no penalty, so the slip costs the vendor nothing — which is a negotiation fix. Notice that only one of the three is an engineering problem.

The resulting RMMM entry: mitigate by building a locker simulator in the first increment that speaks the published wire protocol, and by negotiating a dated delivery clause into the purchase order; monitor the vendor's release cadence and their median forum response time, reviewed at every second stand-up by a named owner, with the driver's test pass rate against the simulator as a second indicator; manage by shipping release 1 as reserve-and-collect-from-the-librarian with the locker path behind a feature flag and the field trial moved into release 2 — with the trigger stated in advance as the SDK has not arrived by the end of week 6. The simulator cost about two weeks of one developer, against a risk exposure of 22,800 dollars. That is the arithmetic that authorised it, and it is the sentence an examiner is looking for.