Process Control Plan: How to Hold the Gain After the Project Team Leaves

A Process Control Plan documents the control mechanisms for each process step. For every step you record what is monitored, the specification it must meet, the method used to monitor it, how often the check happens, who owns it and what to do when the check fails.

You use it in the Control phase of RDMAICS, after the improvements are in place and verified. By that point you know which inputs drive the output. The control plan is where you turn that knowledge into a routine that survives without you.

The timing matters. If you write the plan too early, you lock in controls for a process you have not finished changing. If you write it too late, the project team has already dispersed and the knowledge leaves with them. Build it while the Improve work is still fresh and the owners are still in the room.

Think of the plan as the handover document. The team moves on. The plan stays.

The tool opens with sample data already loaded, so you can see the shape of a finished plan before you build your own. The example follows an accounts payable process from the moment an invoice arrives to the moment payment is posted. This example is fictional and is included for illustration only.

Five process steps are controlled. Invoice receipt, OCR data capture, three-way match, approval routing and payment posting. Each one carries a single characteristic that is worth watching, a specification, a control method, a frequency, a named owner and a reaction plan.

Five steps is a sensible size. A control plan that lists every task in a process becomes a document nobody reads. A plan that covers the handful of steps where quality is actually created or lost becomes a working tool.

Each row of the worksheet is one process step. Work left to right and the structure becomes obvious.

Step 1, invoice receipt, monitors scan quality in DPI against a specification of at least 200 DPI. The control method is an auto-check plus a p-chart, run every batch, owned by the AP Clerk. If a scan fails, the reaction is to rescan or reject.

Step 2, OCR data capture, monitors field error rate against a specification of 8 per cent or lower. The method is sampling plus an I-MR chart, run daily, owned by the Green Belt. The reaction is to re-verify the batch.

Step 3, the three-way match, monitors match rate against a specification of 95 per cent or higher. A dashboard alert runs in real time, owned by the AP Manager, and the reaction is to route the exception. Step 4, approval routing, monitors approval cycle time against a specification of 4 hours or less using a daily time-series monitor, also owned by the AP Manager, with escalation to a delegate as the reaction. Step 5, payment posting, monitors posting accuracy against a specification of 100 per cent using a daily reconciliation report, owned by the AP Clerk, with a reaction to correct and log.

The tool summarises the worksheet into a short control output. Five steps are controlled. Five of five carry a specification. Five of five carry a reaction plan. Three owners cover the five steps.

The frequency breakdown is reported as well. Every batch on 1 step, Daily on 3 steps, Real-time on 1 step. That single line tells you the rhythm of the control system. Most of the monitoring load sits in a daily routine, with one real-time alert and one batch-level check.

Those completeness counts are the part worth dwelling on. A control plan with a gap in the specification column means somebody is monitoring a number without knowing what good looks like. A gap in the reaction column means somebody will see a failure and have no instruction. Five of five on both columns means the plan is closed.

The tool also offers an AI review that explains the result in plain language if you want a second read before you circulate the plan.

A finished control plan answers questions that otherwise generate meetings. Who is watching this number. How often. What happens when it drifts. The plan answers all three on one page.

In the example, three owners carry five steps. The AP Clerk owns steps 1 and 5. The AP Manager owns steps 3 and 4. The Green Belt owns step 2. That distribution is itself a decision point. The Green Belt holding step 2 is a signal worth noticing, because a Green Belt is usually a project role rather than a standing operational role.

The first mistake is monitoring the output only. A plan that watches the final result tells you when you have already failed. The example watches scan quality at step 1 and field error rate at step 2, upstream of the three-way match. Those are inputs. Control the input and the output follows.

The second mistake is a vague reaction plan. Phrases such as investigate or review are not reactions. They are intentions. Every reaction in the example names an action the owner can take without asking permission.

The third mistake is assigning ownership to a team rather than a role. A team does not notice a chart drifting. A named role does. The example assigns AP Clerk, Green Belt and AP Manager, which is specific enough to act on.

The fourth mistake is over-frequency. If you set every check to real-time, nobody sustains it. The example runs one real-time check, three daily checks and one every batch. That is a load a working team can carry.

A control plan is a living document. The process will change. New systems arrive, volumes shift, people move roles. A plan written once and filed becomes wrong quietly.

Set a review date when you hand the plan over. At review, check three things. Are the specifications still the right targets. Are the owners still in those roles. Has any reaction plan been triggered, and did it work.

The reaction log is the most useful evidence you will gather. Step 5 in the example asks the owner to correct and log. That log tells you whether the control is catching real problems or firing on noise. Either answer is useful at review.

The Process Control Plan documents controls. It does not operate them. Nothing in the worksheet runs a p-chart, samples a batch or sends a dashboard alert. Those happen in your systems and your routines. The plan records what should happen, not what did.

It does not validate your specifications. The tool counts that five of five steps carry a specification. It cannot tell you whether 200 DPI is the right threshold for scan quality, or whether an 8 per cent field error rate is tolerable for your process. That judgement comes from the Measure and Analyse work that preceded the plan.

It does not test whether the control methods are capable. A sampling plan has a detection probability. A dashboard alert has a false alarm rate. The plan lists the method. Assessing whether that method will actually catch a shift is separate statistical work.

It does not confirm that owners have accepted their roles. Three owners appear in the example, but a name in a column is not a commitment. You get that in a conversation, not in a worksheet.

Finally, it does not measure whether the gain held. The plan is the mechanism. Sustained performance is the outcome, and you confirm that by looking at the process data over the months after handover.