4.1 Delivery Strategy: Big Bang, Phased, Voluntary and Iterative

How change is delivered should be considered before designing the approach. The delivery strategy determines when training must land, how much support resource is needed at go-live, whether learning between groups is possible, and how communication is paced. CM3 examines four basic approaches, each with named examples and change management implications.

The four delivery strategies

What each strategy demands of you

Big bang

The defining constraint is that there is no second chance. Because nobody goes first, nobody has learned anything before the whole organisation is live. Two practical consequences follow.

First, the learning-to-doing gap becomes the critical risk. If you train 800 people over six weeks and everyone goes live on the same Monday, the first group trained has a six-week gap before using anything, and by then most of what they learned has decayed. Bridging that gap — refresher material, quick-reference guides, practice environments kept open — is a named change management concern.

Second, support resource peaks sharply. A lot of support resource, both technical and change, is likely to be needed in the early days after go-live. Under-resourcing this window is one of the most reliable ways to convert a workable change into a failed one, because every unresolved early problem becomes a story that travels.

Phased

Phasing buys you the thing big bang cannot provide: learning between phases. That advantage is only realised if you actually build a mechanism to capture and apply it — a structured lessons review after each phase, feeding into the next.

It also produces success stories from early phases that can be communicated across the whole organisation, which is powerful because it is peer evidence rather than change-team assertion. And it allows training to be staggered so it happens closer to implementation, which directly addresses big bang's decay problem.

Voluntary adoption

Voluntary adoption is the only strategy where you are managing a rate rather than a date. The change management work shifts to tracking adoption rates and considering publishing them — visible adoption numbers create their own social pressure.

Two risks are named. Demand can outstrip the ability to deliver the transition, so an enthusiastic early surge overwhelms the support capacity and creates a bad experience precisely among your most willing adopters. And late holdouts need a deliberate strategy, because the people who wait until the final week are typically those with the most concerns and they will all need support simultaneously.

CM3 also notes that voluntary adoption invites consideration of a diffusion curve when thinking about adoption rates over time.

Incremental and iterative releases

Agile delivery inverts the usual change management pattern. Because releases are frequent and small, lengthy training courses are unlikely to be practical or even necessary, and not all releases will even be noticed by users.

The skill becomes triage: spotting which releases need change management and which do not. CM3 gives the sharp warning that five minutes' work for a software developer could lead to a major process rewrite — technical effort is a terrible proxy for change impact. This is also where minimum viable change practice applies, keeping the change intervention proportionate to each release.

Hybrids

Often the real-world implementation strategy is a hybrid of two or more of the basic approaches. A common pattern is a phased roll-out where each phase is itself a big bang for that site, or a voluntary adoption period followed by a mandatory cut-over date. Identify which characteristics apply to which part rather than forcing a single label onto the whole programme.