A Risk Response Is Not Real Until Someone Implements It

Most risk registers hold at least one response that has never happened. It has a strategy, a name in the owner column, and a date that has been quietly moved twice. It survives review after review because nobody in the review is being asked to prove anything. If the risk ever arrives, everyone finds out at the same moment that nothing was actually put in place.

The uncomfortable part is that the planning was often good. The risk was correctly identified, the analysis was sensible, and the chosen response was proportionate. What was missing was the smallest and least interesting step: someone doing something. A response is not a decision recorded. It is a change in what the project has actually done, whether that is money committed, people released, a clause added to a contract, a supplier put on notice, a test brought forward or a second supply route opened. Until one of those has happened, the register is describing an intention.

That distinction is the reason Section 2.7.2 of the PMBOK® Guide treats Implement Risk Responses as a process in its own right rather than as something that follows automatically from planning them.

Why a planned response feels finished

Risk planning has a natural sense of completion built into it. The analytical work is the visible, effortful part: working out what could happen, how likely it is, what it would cost, which response family fits. By the time a workshop reaches "so we will mitigate it by bringing the integration test forward", the difficult thinking is done and the remaining action feels administrative. The register gets updated, and the update looks like progress because it is the only artefact anyone sees.

There is a second reason, and it is structural rather than psychological. Risk work is frequently run in a parallel track to delivery. The actions agreed in a risk session do not always land in the schedule, the backlog, the resource plan or the budget, which means none of the routine machinery that chases ordinary work is chasing them. Nobody misses a milestone by not implementing a risk response. The work simply has no place to be late.

A blunt diagnostic helps here. If a response were quietly deleted tonight, what would look different on the project by the end of next week? If the honest answer is nothing at all, the response has not started, whatever its status column says.

What has to change before a response counts

Five questions separate an agreed response from an implemented one. They are deliberately practical, and they can be asked in a couple of minutes at a review.

• What is the actual action, described as something a person does? "Mitigate" and "transfer" are strategy families, not responses. "Move the interface test to sprint four" and "add a liquidated damages clause at contract award" are responses.
• Who has accepted it by name, and do they have authority over the resources it needs?
• What does it cost in money, time or capacity, and where is that coming from?
• When does it happen, or what specific condition triggers it?
• How will anyone know it has been done, without asking the owner whether they feel it is under control?

Consider a claims platform migration at a mid-sized insurer. The team identifies a credible risk that average handling time will spike for several weeks after cutover while handlers learn the new screens. The agreed response is a pool of twelve trained overflow handlers available for the first four weeks, and the operations manager is recorded as owner. Everyone leaves the session satisfied, because the response is genuinely the right one.

What that response actually required was a set of things nobody scheduled: twelve people released from their normal service targets, training slots before cutover rather than during it, licences and kit provisioned, a rota, and a threshold at which the pool would be called on. None of it was funded, because none of it appeared in a budget line or a plan. At cutover, the operations manager is judged on this month's service levels, and the twelve people are needed exactly where they already are. The response was never refused. It was simply never brought into existence.

The judgement worth taking from that is about sequencing. The moment to test whether a response is implementable is when it is chosen, not when it is needed. If the response depends on capacity someone else controls, the conversation with that person is part of the response, not a follow-up to it.

Ownership is a commitment, not a column

Naming an owner and obtaining a commitment are different acts, and registers rarely distinguish between them. A name in a spreadsheet often records who is closest to the subject, or who was in the room, or who raised the risk in the first place. What is needed instead is a person who has agreed to a specific action by a specific date and who has the authority to make it happen.

Where the owner lacks that authority, the honest position is that the response is currently a request rather than a plan. That is a legitimate state to be in, but it should be visible as one. It is also the point at which escalation is appropriate, not because the situation is difficult, but because the decision genuinely sits above the person holding it. Escalating a resourcing conflict that the project manager cannot resolve is not an admission of failure, and leaving a response unimplemented in order to avoid the conversation is a far more expensive choice.

Ownership also has a shelf life. People move roles, priorities change, and a response agreed in February may belong to nobody by June. Reviewing owners is not the same as reviewing risks, and it takes a fraction of the time.

Fallbacks, triggers and the day the risk arrives

Contingent responses complicate the picture, because a fallback plan is not supposed to be executed yet. That does not make it exempt. A fallback is implemented when the preparation is in place, the trigger condition is defined in measurable terms, someone is actively watching that condition, and it is clear who can authorise the switch. A fallback that depends on somebody noticing something in general terms and raising it at the next monthly review is not prepared, it is hoped for.

The same applies once uncertainty becomes fact. When a risk occurs it becomes an issue, and the management response changes: the question is no longer whether to prepare, but what to do now and who is accepting the consequences. Teams that have genuinely implemented their responses find this transition undramatic, because the capacity, the clause or the alternative route already exists. Teams that have only agreed their responses discover the gap at the worst possible moment.

Implementation looks different across delivery approaches, though the underlying requirement does not change. In predictive work, responses need to appear in the schedule, the budget and the resource plan, or they are invisible to the controls that run the project. In adaptive delivery, a response usually needs to become a backlog item with a priority, sized and pulled into an iteration like any other work, which is often a more reliable route to implementation than a register entry. In hybrid environments the risk is one of assumption: the governance layer records the response, the delivery teams never see it in their own working system, and both sides believe the other is handling it.

For a PMP candidate, this is less about memorising a list of response strategies and more about recognising the difference between a scenario in which a response has been planned and one in which it has been carried out. Those scenarios point to different correct actions. The current PMP Examination Content Outline places risk work within the Business Environment domain and frames it around planning and managing risk, including executing a risk management plan rather than only producing one, which is the same emphasis in different language. Building the habit of asking what has actually changed as a result of a decision is one of the reasons structured preparation pays off beyond the exam itself, and our PMP® Exam Preparation course works through these situations as project decisions rather than as vocabulary.

On a live project, the practical change is small. Give risk responses the same treatment as any other committed work: a named person who has said yes, a cost, a place in the plan or the backlog, and a check that it happened. A register that records twenty responses of which fourteen exist only on paper is not managing risk. It is documenting good intentions, and it will read as reassurance right up until the point it does not.

Andre Malowney

Interested in going further?

Risk questions in the exam rarely turn on naming a response strategy; they turn on judging what has already been done and what the project manager should do next. Structured preparation gives you enough worked situations to make that judgement quickly and defend it.

The Risk Performance Domain in the PMBOK® Guide Eighth Edition is the fuller reference behind the separation between planning a response and implementing one.

Ad · Amazon affiliate link.

References

A152: The PMBOK 8 Risk Performance Domain: What It Really Covers
A153: Risk vs Issue: The Difference That Changes What You Do Next
A154: When Does a Risk Become an Issue?
A155: Risk Register vs Risk Report vs Issue Log: What Goes Where?
A157: Do Agile and Hybrid Projects Still Use Risk Registers?

PMP and PMBOK are registered marks of the Project Management Institute, Inc.