Portolan Operations decision desk
Open Portolan
All playbooks
Playbook · Change & adoption

Continuous improvement and change adoption

Improvement is a capability, not a campaign. This path uses structured tests, participation and visible adoption management, and it expects the performance dip that follows most real changes.

Start a decision

6 steps · 9 cited sources · free during beta

The question this path answers

How do we make improvement routine, and how do we get a change to stick?

The path, step by step

  1. Define the problem and the target condition

    Write the current condition, the target condition and the gap in observable terms. Separate the operational problem from the solution someone has already chosen.

    Why it worksImprovement starts with a clear problem statement, not a tool. Without a target condition, any activity can be declared progress and the original problem remains.

    EvidenceDeming (1986) · Bessant et al. (2001)

    CheckpointA one-page problem statement with current condition, target and a measurable gap.

    Common failureLaunching a programme before agreeing what problem it is meant to solve.

  2. Run a structured test in one area

    Use a plan-do-study-act cycle on a small scope: predict the effect, run it for a defined period, compare with the prediction and decide to keep, adjust or stop.

    Why it worksParticipatory improvement cycles have been tested in organisational field experiments and can improve employee outcomes; the operational result still has to be measured separately. Small tests limit the cost of being wrong.

    EvidenceDeming (1986) · Schwarz et al. (2017)

    CheckpointA written prediction and a measured result from a bounded test.

    Common failureRolling out a change everywhere before testing it anywhere.

  3. Build participation and local ownership

    Give the people doing the work a routine for raising problems, proposing tests and seeing what happened. Protect the time and make the backlog visible.

    Why it worksContinuous improvement develops through routines and behaviours, and psychological safety determines whether people surface the problems that improvement depends on.

    EvidenceBessant et al. (2001) · Edmondson (1999) · Ichniowski et al. (1997)

    CheckpointA visible improvement backlog, with participation measured by team.

    Common failureAsking for ideas through a suggestion box and never reporting back.

  4. Create improvement infrastructure

    Make improvement part of the operating cadence: a short review, a named owner, a standard test format and a way to spread what worked.

    Why it worksImprovement becomes a capability when it is supported by routines and structures rather than individual enthusiasm. Infrastructure is what keeps it going when the launch energy fades.

    EvidenceBessant et al. (2001) · Shah & Ward (2003)

    CheckpointA recurring review with decisions recorded and tested changes spreading beyond the pilot.

    Common failureRunning improvement as an extra project on top of everyone's day job.

  5. Manage adoption and expect the dip

    Expect performance to fall before it rises. Tell people the dip is expected, watch the leading indicators, and avoid adding pressure that drives the old workaround back.

    Why it worksImprovement programmes often fail because early poor results are attributed to worker effort or programme fit, and the response is more pressure. That reaction reinforces the very system the change was meant to fix.

    EvidenceRepenning & Sterman (2002) · Kotter (1995)

    CheckpointThe dip is visible on a chart, with a pre-agreed response rule instead of a panic.

    Common failureAbandoning the change after the first bad week and confirming that improvement never works here.

  6. Sustain and scale with evidence

    Scale only after the test shows the mechanism working. Keep the measurement, transfer ownership to the line, and prune practices that stop earning their keep.

    Why it worksSustained improvement depends on embedding the practice in local routines and on evidence that it still delivers. Scaling before the mechanism is understood multiplies the failure.

    EvidenceBeer & Nohria (2000) · Schwarz et al. (2017) · Bessant et al. (2001)

    CheckpointThe practice survives a change of sponsor or a busy period, with the measure still being used.

    Common failureScaling a pilot that only worked because of the person running it.

The evidence base

Each step above cites hand-selected research. These are the studies behind the path.

More from the library

Further reading from Portolan's research library, matched by subject. These papers are not proof that any step works; check each checkpoint against your own operation.

  • Tortorella et al. (2019) — Industry 4.0 adoption as a moderator of the impact of lean production practices on operational performance improvement
  • Piercy & Rich (2009) — Lean transformation in the pure service environment: the case of the call service centre
  • Netland & Ferdows (2016) — The S‐Curve Effect of Lean Implementation
  • Samuel et al. (2015) — How did the publication of the book The Machine That Changed The World change management thinking? Exploring 25 years of lean literature
  • Sarkis et al. (2009) — Stakeholder pressure and the adoption of environmental practices: The mediating effect of training
  • Anand et al. (2009) — Dynamic capabilities through continuous improvement infrastructure
  • Browning & Heath (2008) — Reconceptualizing the effects of lean on production costs with evidence from the F‐22 program
  • Bessant & Francis (1999) — Developing strategic continuous improvement capability
  • Edmondson et al. (2003) — Learning How and Learning What: Effects of Tacit and Codified Knowledge on Performance Improvement Following Technology Adoption
  • Fullerton & McWatters (2000) — The production performance benefits from JIT implementation

Guides for this path

Other playbooks