Why Your CI Programme Isn't Working: 90-Day Reset (2026)

You did the Kaizen event. You had the facilitator, the sticky notes, the energy. You identified 12 improvement opportunities. People left the room genuinely excited. And then six weeks later, exactly two of those 12 things had moved, the energy had dissipated, and the frontline workers who participated had quietly gone back to doing things the old way.

If this sounds familiar, you're not alone and you're not failing at something others have figured out. The post-Kaizen momentum collapse is one of the most documented patterns in operational improvement, and it happens to organisations with talented, motivated CI professionals.

This guide is an honest diagnosis of why CI programmes plateau. It covers the structural reasons momentum dies, the difference between a CI event and a CI culture, the role of leadership and middle management, the four friction stages where ideas stall, a worked example of a 90-day reset, what an effective programme looks like at scale using customer benchmarks, the specific patterns that change between manufacturing and knowledge-work environments, and what to do when the answer is "we don't actually want to change."

Why do continuous improvement programmes fail to sustain momentum?

The most common reason is that improvement is treated as an event rather than a system. Kaizen events, workshops, and improvement sprints are useful tools, but they produce temporary states of heightened attention. When the event ends, the daily pressures of production, service delivery, or operations reassert themselves. Without a system that makes improvement a daily habit rather than a periodic event, the gains from individual events erode.

The second most common reason is lack of middle management buy-in. Front-line workers can identify problems and suggest improvements all day long. But if their direct supervisors aren't creating space for improvement activity, aren't following up on submitted ideas, and aren't protecting time for people to work on changes, nothing moves. The CI manager becomes the only person who cares, and one person can't sustain a programme across an organisation of any size.

The third reason is that results aren't visible. When improvements happen and nobody connects them back to the CI programme, the programme loses its narrative. People stop seeing the link between their participation and the outcomes. Over time, participation feels pointless even if real changes are occurring.

The fourth reason, the one nobody likes to write down, is that the programme has been measuring activity rather than outcome for so long that its real performance is invisible. Ten Kaizen events run, 200 people trained, 600 ideas in the system, and nobody can name three changes from the last quarter that produced a measurable operational result. That state is reachable from a programme that is genuinely working and from a programme that has been generating motion without movement for two years. Without an outcome measure, the programme cannot tell which it is.

What's the difference between a CI event and a CI culture?

A CI event produces a concentrated burst of improvement activity in a defined time window. A CI culture produces a continuous low-level stream of small improvements every week, driven by the people doing the work, with periodic larger events to tackle bigger problems.

Organisations with genuine CI cultures tend to share a few characteristics. Improvement is built into daily routines: brief team huddles where problems are surfaced, clear channels for reporting issues, fast feedback on whether a suggested change was tried. The ratio of small improvements to big events is high, often 10 to 1 or more. And the people implementing improvements are the same people who identified them, which means there's no handoff gap between idea and action.

Toyota averages roughly one implemented improvement per employee per month across its manufacturing operations. That's not because Toyota employees are unusually creative. It's because the system makes improvement easy, fast, and immediately visible in daily work.

A practical heuristic: if the CI programme produces more events than implemented changes per quarter, the programme is event-led. If it produces more implemented changes than events, the programme is culture-led. Most struggling programmes are deep in event-led mode and trying to escape it by running more events, which is why they don't.

Why does leadership commitment matter so much in CI?

Because continuous improvement almost always requires resources that frontline workers don't control. Time to run trials. Budget to purchase small equipment changes. Authority to modify processes that cross departmental lines. When leadership is nominally supportive but practically absent, improvement ideas that require any of these things simply stop moving.

There's also a signal effect. When senior leaders visibly engage with CI, ask about it in their operational reviews, and treat improvement data as genuinely important information, the whole organisation takes it more seriously. When CI is something the CI manager does while everyone else focuses on "real work," it stays marginal.

Getting and maintaining executive engagement isn't primarily a communication challenge. It's a metrics challenge. Executives engage with programmes that show them numbers they care about. The guide on getting executive buy-in covers the framing and metrics that tend to work best.

The middle-management piece is equally important and harder to fix. Senior leadership can be won over with numbers and quarterly reviews. Middle managers respond to incentives in their day-to-day operating model. If the production supervisor is measured on weekly throughput and the CI programme is treated as a separate axis they don't have time for, the supervisor will deprioritise CI by default. The fix is to fold CI activity into the operating model that supervisors are already accountable for, not to add it as a parallel responsibility.

The four stages where CI ideas stall

An improvement idea has to clear four hurdles to produce a measurable result: submission, evaluation, implementation, and measurement. Programmes that plateau usually have a specific stage where the failure clusters. Diagnosing which stage is the bottleneck is most of the fix.

Submission stage failure

The signal: low submission volume, very narrow set of contributors. The cause: psychological safety or accessibility. Either people do not feel safe surfacing problems, or the channel for doing so is so inconvenient (long forms, desktop-only access, slow approval routing) that they give up. The fix: anonymous submission options, mobile-first channels, and a leader-led launch that explicitly invites the kind of input the programme has historically punished.

Evaluation stage failure

The signal: ideas pile up but few get a decision. The cause: no named owner with authority to decide, or evaluation criteria that are too vague to apply consistently. The fix: name a single decider per idea, define a 14-day SLA from submission to first response, and adopt a triage process so the volume becomes manageable.

Implementation stage failure

The signal: ideas get approved but the changes don't happen. The cause: no resource pool, no time protected for implementation, or no cross-functional authority where the change crosses team boundaries. The fix: dedicate an explicit improvement time block (often 2-4 hours per week per team), and either name a cross-functional sponsor or scope the programme to single-team improvements until you have one.

Measurement stage failure

The signal: changes are happening but the programme can't report what they produced. The cause: nobody has been made accountable for tracking outcomes. The fix: pick three metrics that matter (one financial, one operational, one participation), make one person responsible for reporting them monthly, and tie the programme's funding to the trend.

If you cannot tell which stage is your bottleneck, the answer is usually "more than one." Address them in the order above: submission, evaluation, implementation, measurement. Fixing implementation when nothing is being submitted is a waste of effort.

What are the most common signs a CI programme is plateauing?

The first sign is that the same people are always involved. A healthy CI programme gradually expands its reach to include more of the workforce over time. A plateauing programme has a stable core of engaged participants and a large group of bystanders.

The second sign is that improvement activity concentrates in accessible areas rather than critical ones. Teams improve the things that are easy to improve, while the major constraints on performance go untouched because they're too political, too cross-functional, or too uncertain.

The third sign is that the programme starts feeling like paperwork. When the administrative overhead of documenting improvements, filling out forms, and attending review meetings exceeds the time spent actually improving things, people start gaming the system or dropping out. The process was supposed to serve the improvement, not the other way around.

The fourth sign is that measurement has drifted toward vanity metrics. Number of ideas submitted, number of Kaizen events run, number of people trained. These matter, but if they're what the programme reports to leadership and not the operational impact, something has gone wrong with the measurement system.

The fifth sign, often overlooked, is that the language has become technical. The programme talks about A3s, PDCA, hoshin, and kaizen events while the operational reality of the business is talked about in throughput, defect rate, lead time, and cost-to-serve. When the CI vocabulary diverges from the operating vocabulary, the programme has become a self-contained activity that operations leaders no longer recognise as theirs.

How do you fix a CI programme that has lost momentum?

The first step is an honest diagnostic of where the friction is. Run through the four stages above and identify which one is the primary bottleneck. The fix differs sharply by stage.

The most effective reset I've seen involves a 90-day sprint with a single, highly visible improvement goal that leadership genuinely cares about. Find the one operational metric that leadership is most anxious about right now, run a focused improvement effort on it using CI tools, and measure and report the result explicitly. This reconnects the CI programme to outcomes leadership values and rebuilds the business case for investing in it.

A worked example: a 90-day reset

To make this concrete, here is what a focused reset looked like for a 600-person logistics operation whose CI programme had been running on autopilot for two years.

Day 1: the operations director chose one operational metric, on-time despatch rate, that had drifted from 96% to 89% over the year and was directly visible to the executive team. The CI manager scoped the reset to this metric only.

Days 1-15: a structured idea challenge ran across the despatch operation, asking specifically: "what is one thing we could change in the next 30 days that would help on-time despatch without adding cost?" 47 submissions came in. Triage was completed inside one week using a three-pile method. 11 ideas advanced to evaluation; 24 received a Not Now reply with a specific reason; 12 were grouped together for clarification.

Days 16-45: the 11 advancing ideas were grouped into three workstreams: dock-paperwork redesign, container-labelling, and a small change to the shift-handover briefing. Each workstream had one named owner, a budget cap of £2,000, and a 30-day implementation window.

Days 46-75: implementation. Two of the three workstreams shipped on time; the third (container labelling) needed a one-week extension because of a vendor dependency. Nothing about the changes was dramatic. Each was a small process or signage tweak.

Days 76-90: measurement. On-time despatch rate climbed from 89% to 94%. The operations director reported the result at the next executive review with the specific changes named, the costs (under £6,000 total), and the implementation timeline. The CI programme was visibly tied to a number that mattered.

The result mattered less than the loop closing visibly. The programme had moved from generating activity to producing outcome, and the executive team treated it differently after the reset. Four more 90-day cycles ran in the following year, each tied to a specific metric leadership cared about. The programme was alive again.

What this looks like at scale: customer benchmarks

Three customer programmes show what a working improvement system produces at different scales and in different sectors. The mechanics are unspectacular and that is the point.

Halfords (UK retail and automotive services)

Halfords runs a structured idea programme using Hives.co across 1,000+ engaged colleagues and 400 stores. Over six months, the programme tracked 515 implemented ideas worth more than £759,000 in measurable value. Most of those were small operational improvements identified by store colleagues, evaluated quickly, and implemented inside the same operating quarter. There was no big Kaizen event behind that number; there was a system that made small improvements easy to surface and visible to everyone.

VINCI Energies (energy and digital solutions, global)

VINCI Energies, with 90,000 employees across 2,200 business units in 55 countries, runs a federated CI model on the same platform. Each business unit runs its own improvement campaigns in its own language and against its own priorities, with shared evaluation criteria so good ideas can move between entities. The Innovation Department reports that the most valuable outcome is identifying common challenges across entities that did not previously interact. A solution found in one country becomes available to a team thousands of kilometres away facing the same problem.

Linköping Municipality (Swedish public sector)

Linköping Municipality, serving 160,000+ residents, ran a structured employee idea programme that produced 200 ideas in three months and reduced administrative effort in the idea process by 66%. The lesson is that even highly regulated environments with rigid processes can run continuous improvement well if the governance is clear: short feedback cycles, written evaluation reasons, and visible implementation in everyday work.

The common thread across all three is that the software is the floor, not the ceiling. The platform makes the process easy to run; the discipline of running it is what produces the result. None of these programmes is built on a marquee Kaizen event; all are built on a system that handles small improvements at high frequency.

What changes between manufacturing and knowledge-work CI

The principles are the same. The implementation differs sharply, and trying to use one process for both fails on practical details.

Manufacturing and frontline operations

Submissions are usually condition-based and operational: a process step that takes longer than it should, a piece of equipment that fails predictably, a quality issue that clusters around new starters. Implementation is often low-cost but needs clear ownership at the site level. Recognition has to be visible on the shop-floor board or in the shift briefing; email alone is invisible to operators. Mobile and QR-code submission are foundational, not optional.

Office and knowledge work

Submissions are usually about workflow, handoff, or tool friction: a duplicated approval step, a report that gets generated and never read, a meeting series that adds no value. Implementation often involves IT or vendor dependencies, which slows the cycle. Recognition by email and dashboard works because the audience is at a screen anyway, but the temptation to overcomplicate the process is higher because the participants are comfortable with administration.

Healthcare and regulated environments

Submissions cluster around safety, patient experience, and clinical pathways. Implementation almost always requires clinical sign-off and sometimes regulatory review, which extends the cycle. The biggest CI design choice in healthcare is what scope is delegable to local change versus what has to escalate, and being explicit about that boundary stops the programme from accidentally generating ideas that have no path to action.

In mixed-environment companies, run separate campaigns on a shared platform with aligned evaluation criteria. Continuous improvement software for manufacturing differs in ergonomics from a generic idea-management tool.

What role do frontline workers play in a successful CI programme?

The central one, though they're often treated as an afterthought. Frontline workers have the most granular, real-time knowledge of where processes break down. They see the same problems every day. They have often already thought of solutions but assumed nobody wanted to hear from them.

The challenge is that many CI programmes weren't designed with frontline accessibility in mind. Submission forms that require long written descriptions aren't built for someone on a factory floor or in a retail environment. Review meetings scheduled during production hours don't include shift workers. Recognition systems that use email and corporate portals don't reach people without desk jobs.

If frontline engagement is the gap in your programme, the guide on getting frontline workers to share ideas covers the specific design choices that improve accessibility and participation in operational environments.

How does idea management software fit into a CI programme?

Software is an enabler, not a solution. The organisations that get the most value from CI platforms are those that already have a functioning improvement system and use software to make submission easier, tracking more consistent, and reporting more visible. Software doesn't fix a programme that lacks leadership commitment, middle management buy-in, or a clear process for what happens to ideas after submission.

That said, the right software does meaningfully reduce the friction in the system. When submitting an idea takes 30 seconds from a mobile device and the submitter automatically receives a status update within 48 hours, participation rates improve. When improvement data is aggregated and visible in dashboards that leaders actually look at, the programme stays on the agenda. The operational environments most likely to benefit are those with distributed workforces, multiple sites, or high submission volume that's difficult to manage manually.

If you're evaluating CI software specifically for a manufacturing environment, the guide on continuous improvement software for manufacturing covers the features and trade-offs worth understanding.

Common mistakes when trying to reset a CI programme

Resetting by adding more events

The instinct when momentum dies is to schedule another Kaizen event. This usually fails because the event was the symptom, not the cure. The reset should add system, not events: cadence, named owners, SLA, visible metrics. Events can come back later, anchored to the system.

Renaming the programme

Calling it "Continuous Excellence" instead of "Continuous Improvement" produces no operational change. Workforces are extremely good at recognising re-branding without substance, and a relaunch that is mostly cosmetic actively damages credibility for the next attempt.

Bringing in an external consultant without a clear mandate

Consultants are useful for diagnosis and for the methodology pieces operations teams haven't seen before. They are usually not useful for sustaining day-to-day cadence. The reset has to be owned by an internal sponsor with operational accountability; the consultant is a tool, not the owner.

Skipping the honest conversation about why the last attempt died

People remember. If the previous CI launch generated submissions that were ignored, those people are still in the organisation, and they will not engage again until they hear an explicit acknowledgement of what went wrong and what is different this time. Trying to relaunch as if the previous attempt didn't happen reliably produces lower participation than the original launch.

Conflating improvement with cost reduction

If every CI campaign comes back to "where can we cut?", participation evaporates. Frontline workers will not contribute ideas that they fear will eliminate jobs, and they will route safety, quality, and ergonomics ideas through different channels. Treat cost reduction as one of several improvement vectors, not the only one, and the participation pattern changes inside one cycle.

The honest question to ask yourself

Before any process changes, tools, or reset campaigns, it's worth asking a single honest question: does the organisation actually want to change how it operates, or does it want to feel like it does?

This sounds harsh, but it's useful. Some organisations have genuine appetite for operational change and just need better systems. Others have cultural or political constraints that make real improvement difficult regardless of how well the CI programme is designed. Knowing which situation you're in determines whether the right next step is a better process or a harder conversation.

If you want to diagnose your specific situation more precisely, the innovation programme diagnostic covers many of the structural factors that apply equally to CI programmes and broader innovation programmes.

Frequently asked questions

How long should a CI reset take to show results?

A focused 90-day sprint targeting one operational metric is the right length to show whether a reset is taking. If after 90 days you cannot point to one numerical movement on a metric leadership cares about, the reset has not landed and you need to re-diagnose rather than push for another 90 days. The pattern that works almost without exception is short cycles with visible outcomes, repeated four times a year, rather than one long cycle with a delayed assessment.

Should the CI programme be merged with the broader idea-management programme?

Usually yes, with separate workflows. Trying to keep CI and innovation as separate programmes creates duplicated infrastructure, duplicated submission channels, and duplicated reporting. A shared platform with two workflows (CI ideas route to operational owners with a 48-hour SLA; innovation ideas route to strategic sponsors with a longer evaluation cycle) is usually cleaner. The exception is in regulated environments where CI has formal compliance ties that innovation does not, in which case the workflows need to remain independent even if the platform is shared.

What's the right cadence for CI reporting to leadership?

Monthly to operations leadership, quarterly to the executive team, with one well-curated metric per cycle. The temptation is to report everything because it shows activity, but executive teams will tune out long dashboards. A one-page CI report each quarter that shows three metrics (financial impact, operational metric, participation breadth) and names two or three implementations is usually enough to keep the programme on the agenda.

Should we offer financial rewards for implemented CI ideas?

Usually no for ongoing CI; sometimes yes for specific challenges. Sustained CI programmes that depend on monetary rewards drift toward gaming and away from the kind of small, frequent improvements that produce compounding value. Visible recognition, written thanks, and seeing the change implemented are stronger drivers of repeat participation than cash. A token or small prize for an implemented idea is fine; a formal bounty system tends to distort the kinds of ideas that get submitted.

How do I know if it's a CI problem or an organisational problem?

Run the four-stage diagnostic above. If three or more of the four stages are broken simultaneously, it is an organisational problem rather than a CI design problem, and the right next step is the harder conversation with leadership about whether the operating model can support continuous improvement at all. If one or two stages are broken, it is a CI design problem and you can fix it without needing a broader reset.

What about works councils and unions?

Engage them early, especially if your CI programme collects performance data tied to individuals. In Germany, France, the Nordics, and several other European jurisdictions, employee representatives have legally protected co-determination rights over systems that touch performance or behavioural data. Anonymity options, retention rules, and explicit policies on AI in evaluation are typically the points of negotiation. Works councils are rarely opposed to CI itself; they are opposed to surveillance and lack of transparency.

Can a CI programme work in a service business or only in manufacturing?

It works in both, but the patterns differ. Manufacturing CI tends to produce condition-based, equipment-anchored improvements; service-business CI tends to produce workflow, handoff, and customer-experience improvements. The cycle time is often longer in services because more changes have IT or process dependencies. The principles are identical: surface, evaluate, implement, measure. The implementation tactics are sector-specific.

How do we handle the "we tried this before and it failed" baggage?

Acknowledge it explicitly in the relaunch. "We have run CI programmes here before that produced submissions and no follow-through. Here is what we are doing differently this time: a named decider, a 14-day response SLA, and visible quarterly outcomes tied to operational metrics." Trust is rebuilt by being specific about what changed, not by hoping the previous attempt was forgotten.

What if the only metric leadership cares about is cost?

Frame the early reset around cost so the programme earns the credibility for broader scope. Once leadership has seen one or two cycles produce measurable cost outcomes, the conversation about safety, quality, and customer experience becomes much easier because the programme has banked operational wins. Trying to argue for a multi-vector CI programme before the programme has produced any wins is usually a losing position.

Related guides and case studies

• Halfords: 515 employee ideas turned into £759,000 in value
• VINCI Energies: idea management at group scale
• Linköping Municipality: 200 ideas in three months
• How to get frontline workers to share ideas
• Continuous improvement software for manufacturing
• Employee-driven continuous improvement
• How to measure an innovation programme
• How to triage 100+ ideas in 2 hours
• Your first idea challenge: from question to decision in 10 days