Week 24: The Sustainability Myth: Why Most Improvements Revert Within 6 Months
The Sustainability Myth: Why Most Improvements Revert Within 6 Months
I have a provocative opinion about sustainability in continuous improvement.
If you have to "make" an improvement sustainable, it wasn't a real improvement.
I know that sounds harsh. I know it challenges a core assumption in the CI profession. Sustainability is supposed to be the holy grail — the final step of every project, the metric that separates success from failure, the thing we all chase and rarely achieve.
But after twenty years, forty-plus organisations, and more than a billion dollars in documented savings across Shell, Johnson Controls, KCA Deutag, and dozens of consulting engagements — I've come to a conclusion that most CI professionals don't want to hear.
The reason most improvements revert is not that people failed at sustainability. It's that the improvement never changed the system. It only changed the behaviour. And behaviour without system change is temporary.
Always.
Let me explain with a story.
This was at Shell. Two improvement projects, running roughly in parallel, at two different sites within the same geography. Both addressed similar problems — process inefficiencies that were creating delays and cost overruns. Both were well-structured, properly governed, and led by competent practitioners. Both delivered measurable results.
The first was at a site in Malaysia. The team had identified a chronic issue in their maintenance scheduling process. Work orders were being created, approved, scheduled, and then rescheduled — sometimes three or four times — because parts weren't available when the work was planned. The rescheduling cascaded through the system, creating backlogs, overtime, and missed maintenance windows.
The team's improvement was elegant. They didn't just fix the scheduling. They changed the system. They implemented a parts-availability check that was integrated into the work order creation step. The system physically would not allow a work order to be scheduled until the required parts had been confirmed as available in the warehouse. If the parts weren't there, the work order went into a holding queue with an automatic procurement trigger.
No training required. No behaviour change required. No discipline required. The system made the old way — scheduling without parts confirmation — impossible. You couldn't do it. The process wouldn't let you.
Eight years later, when I checked, that improvement was still in place. Not because anyone was maintaining it. Not because someone was auditing compliance. Because the system didn't allow regression. The old way was physically impossible.
The second project was at a site in the UK. Similar type of problem — a process inefficiency in how maintenance priorities were communicated between the planning team and the execution team. The solution was a new communication protocol: a daily handoff meeting where planners and executors aligned on priorities, discussed resource constraints, and agreed on the day's schedule.
The meeting was brilliantly designed. Clear agenda. Strict time limit. Visual boards. Defined roles. When it ran as designed, it worked beautifully. Communication improved. Priority conflicts dropped. The team delivered a measurable reduction in maintenance delays.
Then the CI practitioner moved on. The supervisor who had championed the meeting got promoted. A new supervisor came in and decided the meeting was "one more thing we don't have time for."
Within eight weeks, the meeting stopped. The old communication problems returned. The delays came back. The improvement reverted completely, as if it had never happened.
Same company. Same CI methodology. Same governance. Same type of problem. But fundamentally different approaches to the solution.
One changed the system. The other changed the behaviour.
The system change lasted eight years and counting. The behaviour change lasted eight weeks.
This distinction — system versus behaviour — is the single most important concept in improvement sustainability. And it's the one most CI programmes get wrong.
Most improvement projects produce solutions that depend on people doing something differently. A new process step. A new checklist. A new meeting. A new way of recording data. A new communication protocol.
These solutions work as long as someone is watching. As long as the CI practitioner is there to coach. As long as the supervisor is committed. As long as the champion hasn't left the organisation. As long as the project is fresh and the energy is high.
But the moment attention shifts — and it always shifts — the behaviour reverts. Not because people are lazy. Not because they don't care. Because the system is still set up for the old way. The system is path of least resistance. And path of least resistance always wins.
I've seen this pattern so many times I can predict it. Any improvement that relies primarily on people remembering to do something differently will revert within three to six months. Some last longer. A few make it a year. But the vast majority follow the same trajectory: initial compliance, gradual erosion, complete reversion.
The exceptions are always improvements that changed the system itself.
Let me give you the framework I use.
When I evaluate an improvement for sustainability, I ask one question: if nobody watches, does the improvement survive?
If the answer is no — if the improvement depends on ongoing supervision, auditing, or reinforcement — then the improvement is a behaviour change, not a system change. And behaviour changes are inherently fragile.
If the answer is yes — if the process itself prevents the old way from recurring — then the improvement is a system change. And system changes are inherently durable.
The hierarchy is clear. Error-proofing beats training. System design beats procedures. Physical constraints beat policy compliance. Automation beats discipline.
This isn't new thinking. Shigeo Shingo talked about poka-yoke — error-proofing — decades ago. The concept is as old as lean itself. But in my experience, most CI programmes still default to behaviour-based solutions. They train people. They write procedures. They create checklists. They hold meetings.
These are all valid tools. But they're the weakest tools for sustainability.
At Johnson Controls, I saw this play out across the EMEA region in a quality improvement initiative.
The problem was recurring defects in a specific product line. The team did excellent root cause analysis. They identified the failure mode. They developed a countermeasure. The countermeasure was an inspection step — a visual check that the operator would perform at a critical point in the assembly process.
They trained every operator. They created a visual aid. They added the step to the standard work document. They tracked compliance for six weeks, and it was above ninety-five percent. The defect rate dropped by eighty percent. Project closed. Success.
Four months later, the defect rate was back to its original level. The inspection step was being skipped by about forty percent of operators. Not out of malice. Out of time pressure, muscle memory, and the simple fact that when you're doing repetitive assembly work at pace, an added manual step is the first thing that erodes.
I asked the team: why didn't you error-proof this? Why didn't you design the process so that the defect couldn't occur in the first place, rather than adding an inspection to catch it?
The answer was honest: because training was faster and cheaper than redesigning the fixture.
That's the trade-off most organisations make. They choose the fast, cheap solution — training, procedures, meetings — over the slower, more expensive solution — redesign, automation, error-proofing. And they pay for it in reversion. Every time.
At Shell, the teams that produced lasting improvements shared a common approach. Before closing any project, they asked: what's the weakest link in our solution? If that weakest link was a person remembering to do something, they redesigned.
They turned manual checks into automated checks. They turned procedural steps into system constraints. They turned "remember to" into "the process won't let you not."
This took longer. It cost more upfront. It required engineering support, IT involvement, and sometimes capital investment. But the improvements lasted. Years later, they were still in place.
The projects that relied on behaviour — new meetings, new checklists, new procedures — had a half-life of about four months. The projects that changed the system — new process designs, new automation, new physical constraints — lasted indefinitely.
The total cost of the system change was almost always lower than the total cost of the behaviour change, because the behaviour change had to be continuously reinforced. The system change was a one-time investment.
Here's my challenge to every CI professional and every leader who sponsors improvement work.
Stop asking "how do we sustain this improvement?" Start asking "how do we design this improvement so that it doesn't need sustaining?"
If the answer is "training and compliance," the improvement is fragile. Redesign.
If the answer is "the process itself prevents the old way," the improvement is robust. Move on.
This is harder. It requires more creativity. It requires deeper understanding of the process, the system, and the constraints. It requires collaboration with engineering, IT, and operations design. It's slower upfront.
But it's the difference between improvements that last eight weeks and improvements that last eight years.
I've been doing this for twenty years. And the single most frustrating thing I've witnessed in continuous improvement is watching teams do excellent problem-solving, develop genuine countermeasures, and then implement them in a way that guarantees reversion.
They do the hard work. The analysis is thorough. The root cause is correct. The solution is sound. And then they implement it as a procedure change, a training update, or a new meeting — and wonder why it doesn't last.
It doesn't last because the system is still set up for the old way. And the system always wins.
Change the system.
So here's my question. Think about the last three improvements your team implemented. For each one, ask: if nobody watches, if nobody audits, if nobody reinforces — does the improvement survive?
If the answer is no for even one of them, you have a sustainability problem. And the solution isn't more training or more auditing. The solution is redesigning the improvement so the old way is impossible.
System beats behaviour. Every time.
If you want the templates and frameworks to design improvements that last — including error-proofing checklists, sustainability assessment tools, and standard work formats that embed change into the process itself — the CI Mastery Toolkit gives you twenty-five professional templates for exactly this. Find it at stormholt.org/products/ci-mastery-toolkit.
New to Stormholt? Start here — it locates your stage in minutes.
Building capability? Stage III — Skill — the tools, the courses, the simulations.