Newsletter Infographic
This visual explains why improvement gains backslide after project close, what failure modes undermine the Control phase, and which concrete sustainment moves keep results alive after the celebration meeting. Click the thumbnail to enlarge it.
The Reality of Backslide
The infographic frames the backslide problem in direct operational terms. Projects may show strong short-term data and still fail to hold their gains. The pattern is familiar: the metric improves, leadership reallocates attention, the team assumes the new result is now normal, and the old process logic quietly returns.
- 70 percent of projects lose gains within a year: the improvement exists, but it is not protected.
- Four months is often enough for regression to start: drift begins well before the annual review sees it.
- Teams often cite “no monitoring plan” as the root cause: the project ended before the control system actually started.
This is the core Control phase illusion: assuming that a documented control plan equals a functioning control system.
The Anatomy of Failure
The failure pattern shown in the visual is structurally sound. Improvement gains disappear because several common forces reinforce each other after the project team exits.
The Illusion of Success
Early positive data is often treated as proof of permanent change. Teams see the metric move and mentally declare victory before the process has survived staffing changes, demand swings, shift variation, maintenance disruption, or management turnover.
Knowledge Transfer Gaps
Operations teams frequently inherit controls they did not help design. If the new method, escalation logic, reaction plan, or reason for the control is not transferred properly, the control becomes decorative. The document exists. The behavior does not.
Pressure Rewrites the System
Resource reallocation, milestone pressure, and schedule compression all push teams back toward the old way of working. Under pressure, people do not usually default to the ideal state. They default to the habit that still feels operationally familiar.
Confirmation Bias
Once a project is labeled successful, teams often start interpreting weak signals in a way that protects the success story. This delays recognition of regression and extends the time before corrective action is taken.
Why the Control Phase Is So Often Weak
In many DMAIC projects, the Control phase is treated like documentation closeout rather than system installation. The team produces a control plan, updates a few files, signs the tollgate, and moves on. But a real control system requires more than paperwork.
| Weak Control Pattern | What It Looks Like | Consequence |
|---|---|---|
| Ownerless controls | The control is assigned to a department, not a named person. | No one feels accountable when the signal starts to drift. |
| Undefined response limits | The team monitors a metric but never defines what triggers action. | Control charts and dashboards become observation tools instead of intervention tools. |
| Document-only handoff | The new process is transferred by email or shared folder. | Operations receives files but not working ownership or understanding. |
| No time-bound review cadence | There is no 90-day or 180-day review scheduled before project closure. | Regression appears long before anyone formally checks it. |
| Controls outside the operating system | The control lives in a project document, not in dashboards, SOPs, PM schedules, or tier boards. | The process improvement is not anchored into daily work. |
The $340,000 Regression Case
The infographic’s warehouse throughput example captures the failure clearly. The project delivered real initial results: cycle time fell and errors dropped materially. On paper, it looked like a strong closeout candidate.
Ten months later, the cost of failed control reached $340,000. The handoff unraveled because the team relied on a short-term check instead of a genuine long-horizon monitoring system. The financial result matters because it forces the right question: was the project really complete, or was it only temporarily improved?
The point is not that one warehouse slipped. The point is that improvement gains are fragile when the control system is thinner than the improvement itself.
Seven Strategies for Permanent Gains
1. Define a Six-Month Monitoring Horizon
Do not stop at the first 30- or 50-day check. A stable Control phase should survive at least one full cycle of normal operational disruption, including staffing variation, demand shifts, and routine noise.
2. Assign Named Owners, Not Departments
Every critical control needs a specific person with a title and a review calendar. Group ownership is often diluted ownership.
3. Set Limits and Defined Responses
Monitoring without thresholds is not control. Teams must define what deviation looks like, who acts, how quickly they respond, and what escalation path is used if the process moves out of condition.
4. Build the Handoff, Not Just the Document
Documentation matters, but it is not enough. A real handoff requires walk-throughs, verification, operator understanding, leader understanding, and proof that the receiving team can run the control system without the project team standing beside them.
5. Pre-Schedule 90- and 180-Day Reviews
Formal sustainment reviews should be on the calendar before project closure. Otherwise the review gets treated as optional and then disappears under normal workload.
6. Anchor Controls in Daily Systems
If the control only lives in the project binder, it will fade. Embed it into SOPs, dashboards, PM schedules, team boards, audit routines, and automation wherever possible.
7. Redefine Project Success
Success should not be defined at closeout. It should be defined at the point where the gains are still present months later without heroics. That raises the bar, but it also makes the result real.
Project Closure Readiness Checklist
The visual closes with the right checklist logic. Before a project is declared complete, leaders should be able to answer yes to a set of direct sustainment questions:
- Has a long enough monitoring horizon been defined?
- Are named owners assigned to the critical controls?
- Are control limits and response steps explicit?
- Has the handoff been verified through real walkthroughs rather than file transfer?
- Are 90-day and 180-day reviews already scheduled?
- Are controls embedded into the operating system rather than left in project-only documents?
- Is success being defined in terms of sustained performance instead of short-term improvement?
If several of those answers are still no, the project may be improved, but it is not yet controlled.
What This Means for Lean Six Sigma Teams
The Control phase should be treated with the same seriousness as root cause validation. Most teams would never accept an Improve phase based only on enthusiasm and a signed memo. Yet many teams accept a Control phase based on exactly that level of evidence.
If the organization wants durable results, the sustainment design must be engineered. That means specifying ownership, reaction logic, review timing, operating-system integration, and transfer quality with the same discipline used earlier in the project.
Download and Share This Issue
Use this issue with Green Belts, Black Belts, supervisors, operational leaders, and project sponsors who need a more rigorous view of what Control really requires after implementation.
Final Thought
Improvement that is not sustained is not finished improvement. It is a temporary spike. The Control phase only works when the receiving system can hold the gain after the project team leaves. That is the real test.