Reaction Plan: Keep the Gain After the Project Team Leaves

The Reaction Plan sits in the Control phase of RDMAICS. Its job is narrow and useful. For each controlled characteristic, you document the step-by-step reaction when the metric breaches control limits.

Improvement projects end. The team disbands. The Green Belt moves to the next problem. What stays behind is a process, a chart and a group of people who were not in the room when the solution was designed. The Reaction Plan is the bridge. It converts project knowledge into an instruction that someone can follow at eight in the morning with a queue building up.

Use it once you know which characteristics you will monitor and what good looks like. That usually means your control charts or limits are set. The Reaction Plan then answers the next question. When the chart goes red, who does what, in what order, and by when.

Reach for the Reaction Plan at handover. The moment you are about to tell an operational owner that the process is theirs now, you need a written response for each trigger.

It is also worth building when an existing control is failing in practice. If a metric drifts and nobody acts, the usual cause is not laziness. It is the absence of an agreed first move. People wait for permission. A Reaction Plan grants that permission in advance.

The tool suits any characteristic with a measurable trigger. Error rates, cycle times, defect counts, duplicate events. If you can say what breach means, you can write a reaction.

The screenshots in this guide show the tool loaded with its built-in sample data. The case is fictional. It describes an accounts payable process that has just finished an improvement project and is moving into steady running.

Three characteristics are under control. Field error rate, cycle time and duplicate rate. Each has a trigger, four response steps and a named owner.

The first characteristic is field error rate. The trigger is greater than eight per cent for two days. Contain by switching to manual QA. Notify the AP Manager. Investigate by inspecting the OCR template. Correct by re-training the OCR engine. The owner is the Green Belt.

The second is cycle time. The trigger is a trend above four hours. Contain by auto-delegating approvals. Notify the Sponsor. Investigate by reviewing the approval matrix. Correct by updating delegation rules. The owner is the AP Manager. The third is duplicate rate. The trigger is any duplicate. Contain by holding payment. Notify Finance. Investigate by tracing the source. Correct, then prevent. The owner is the AP Clerk.

The worksheet is one row per characteristic. You fill seven fields across that row and the tool does the rest.

Notice the discipline each column imposes. The trigger has to be specific enough that two people would agree it has fired. Greater than eight per cent for two days is specific. Any duplicate is specific. High error rate is not.

The four steps are deliberately sequenced. Contain comes first because stopping the bleed matters more than understanding the cause. Notify comes second so the right level of authority knows early. Investigate comes third. Correct comes last, and in the duplicate row it extends to prevention.

The result panel summarises completeness rather than performance. That is the right measure for this tool. A Reaction Plan is only useful if it has no gaps.

The output shows three characteristics from the worksheet. Trigger defined reads three of three. All response steps set reads three of three. Owners reads three. The tool states that each trigger has its contain, notify, investigate and correct steps set.

Below that, the result lists each characteristic by number with its containment action and its owner. One, switch to manual QA, Green Belt. Two, auto-delegate approvals, AP Manager. Three, hold payment, AP Clerk. That short list is the part worth printing. In a breach, the first move and the responsible role are all anyone needs to read.

The tool also offers an AI review that explains the result if you want a second read on the plan.

The first decision is whether you can hand over at all. If trigger defined read two of three, you would not be ready. A characteristic you monitor without a documented reaction is a chart nobody acts on. The completeness counts make that argument for you in a governance meeting.

The second decision is about authority. Look at the ownership spread in the sample. Three characteristics, three different owners, at three different levels. The Green Belt holds the technical fix for the OCR template. The AP Manager holds the approval rules. The AP Clerk holds the payment hold. Each action sits with the role that can actually perform it without asking.

The third decision is escalation design. Notify steps differ by row. Field error rate notifies the AP Manager. Cycle time notifies the Sponsor. Duplicate rate notifies Finance. That tells you the team thought about who needs to know, rather than copying one recipient into every row.

The fourth is the containment choice itself. Switching to manual QA costs effort. Auto-delegating approvals changes who signs. Holding payment affects a supplier. Each is a trade you accept in advance so nobody has to negotiate it under pressure.

The most common mistake is a vague trigger. If the condition is open to interpretation, the reaction never starts. Compare the sample rows. Greater than four hours trend and any duplicate both leave little room to argue.

The second mistake is naming a team instead of a person or role as owner. A plan owned by everyone is owned by nobody. The sample names Green Belt, AP Manager and AP Clerk. Each is a single accountable role.

The third is skipping containment and jumping to the fix. Investigation takes time. Without a contain step, defects keep flowing while you diagnose. The third mistake has a cousin: writing a correct step that is really a wish. Re-train OCR engine is an action. Improve quality is not.

The fourth mistake is leaving the plan in the project folder. The Reaction Plan belongs where the process runs, visible to the people on shift.

Be honest about the boundaries. The result counts completeness. It does not judge quality. The tool reports three of three triggers defined. It cannot tell you whether eight per cent is the right threshold for field error rate, or whether four hours is a sensible cycle time limit. Those numbers come from your process capability work and your customer requirement, not from here.

It does not test whether the reactions work. Switching to manual QA may not be feasible if the QA staff are not rostered. Holding payment may conflict with a contractual term. The plan records intent. Only a drill or a real breach proves it.

It does not monitor anything. The Reaction Plan is paper, not a sensor. Something else has to detect the breach and raise the flag. If no one looks at the chart, a perfect plan sits unused.

It does not keep itself current. Processes change, roles change and systems get replaced. A plan that names an OCR template becomes stale when the template is retired. Set a review date and name someone to hold it. The tool documents the reaction. Holding the gain is still done by people.