The Control Plan That Nobody Follows
A project reduced invoice-processing errors from 9% to 2.5% by standardizing a verification step and adding a checklist. Six weeks after the control phase, an audit finds the error rate has drifted back to 6%. Investigation shows: the checklist is stored in a shared drive that was reorganized; two of the four original team members have left and were replaced by temps who were never trained on the new step; the supervisor who championed the change was promoted; and there is no ongoing metric review - the process is measured only in the annual audit. The control plan document exists and is complete on paper. The sponsor considers the project closed and has reallocated the Belt.
1. Explain why the control plan failed despite being 'complete on paper,' and identify the specific control gaps.
Read the worked answer
A control plan is not a document; it is an operating system. This one failed on every element that makes control real.
Why it failed: the control plan described what to control but did not assign who monitors, how often, or what happens when the metric drifts. It was written for the project, not for the process.
Specific gaps:
- No documented control owner. The champion was promoted and no successor was named. With no owner, no one is accountable for the checklist or the metric.
- No training/onboarding control. Two of four team members left; temps were never trained. The control plan had no requirement for training new staff on the new step - a predictable and preventable failure.
- No accessible standard work. The checklist lives in a shared drive that was reorganized. Standard work must be available at the point of use, not in a folder.
- No monitoring cadence. The process is measured only annually. A drift from 2.5% to 6% over six weeks is invisible until the next audit - far too late to react.
- No reaction plan. Even if the drift had been detected, there was no defined trigger, threshold, or response.
- No handover at project close. The Belt was reallocated without a formal transition to the process owner.
Root cause: the control phase was treated as documentation rather than as a transfer of ownership and a monitoring system.
2. Design a control plan that would have prevented this drift. Be specific about owners, frequency, and reaction.
Read the worked answer
Build the plan around four elements: standard, owner, monitor, react.
1. Standard work (point of use)
- Checklist posted at each workstation and embedded in the invoice-processing screen where possible (not a shared drive).
- Version-controlled; changes require the control owner's approval.
- Owner: control owner (named individual, with a named backup).
2. Training and onboarding control
- New staff and temps cannot process invoices independently until they complete a 30-minute checklist training and a supervised sample of 10 invoices with ≥90% accuracy.
- Training record maintained by the supervisor; reviewed monthly.
- Owner: front-line supervisor.
3. Monitoring cadence
- Daily: supervisor spot-checks 5 invoices against the checklist.
- Weekly: error rate calculated and posted on the team board (errors ÷ invoices processed).
- Monthly: control owner reviews the weekly trend against the 2.5% target and the control limits.
- Quarterly: Belt or quality reviews the control plan itself for relevance.
4. Reaction plan
- Trigger: weekly error rate >4% for two consecutive weeks, or any single week >5%.
- Response: supervisor investigates within 48 hours using a simple 5-why; check training records, checklist availability, and any process change. Report to control owner.
- Escalation: if not back under 4% within two weeks, escalate to the department manager and re-engage the Belt.
5. Handover at close
- Formal sign-off: control owner accepts the plan, the metric, and the reaction authority in writing. The Belt is not released until sign-off.
6. Visual management
- Run chart of weekly error rate posted at the process, with target and reaction threshold marked, so drift is visible to the team, not just to management.
3. The sponsor considers the project closed and has reallocated the Belt. What do you recommend, and how do you make the case?
Read the worked answer
Recommendation: Reopen the control phase - not the whole project - and require a formal handover before closure is final. The improvement is not sustained, so the project has not delivered its benefit.
The case to the sponsor:
- Financial framing. The project claimed a reduction from 9% to 2.5%. At 6%, roughly two-thirds of the claimed benefit has already eroded in six weeks. If the trend continues, the project will return to baseline and the investment will show zero return. Closure now books a benefit that is disappearing.
- Precedent framing. Closing projects without verified control teaches the organization that improvements are temporary. Future projects will face the same skepticism and the same erosion.
- Low cost of the fix. The remediation is small: name a control owner, restore the checklist to point of use, train the temps, and set a weekly metric review. This is days of effort, not a new project.
- Specific ask: (a) a named control owner with authority; (b) 30 days of Belt time (part-time) to complete the handover and training; (c) a 90-day post-control audit with a defined success criterion (error rate ≤3% at 90 days).
If the sponsor resists: propose a minimal version - the control owner is named and the weekly metric review starts immediately, with the Belt checking in at 30 and 90 days. Even this minimum would have caught the drift.
The principle: a project is not closed when the solution is implemented; it is closed when the process owner has demonstrably held the gain. Reallocating the Belt before that point is the single most common cause of improvement decay.