Transition States: Why You Can't Jump From Here to There

Most transformation plans define two states clearly: where the organisation is now, and where it's meant to end up. The stretch of time between the two usually gets a line on a project timeline and little else. In my experience that's the part of the programme most likely to go wrong, because it's the only point where the old way of working and the new way of working have to run at the same time.

An optimisation project doesn't have this problem. You install an AI tool into a process that keeps running throughout: the buying team keeps buying, the tool gets better at supporting the decision, and there's no moment where the process stops being one thing and starts being another. Transformation is different by design. When you change who makes a decision, what data it's based on, or how work flows between teams, you can't switch the whole operating model over in a weekend. For a period, no matter how short you plan it to be, the old model and the new model both have to function. That period is the transition state, and it needs designing with the same rigour as the target state itself.

This period is also the most operationally demanding phase of the whole programme. The business still has to trade while it happens. People are learning new ways of working while continuing to do their current jobs, and leadership is running the transformation programme and the normal business at the same time. The support that worked in a pilot, an engaged team, close attention, tolerance for hiccups, doesn't extend to an organisation-wide rollout by default. That's the environment the risks below show up in, which is why designing for them can't wait until they surface mid-programme.

When the gap state isn't planned for

The specific risk inside that period is what the playbook calls the gap state: the old process has been partially retired before the new one is fully able to carry the load. Revenue is exposed, quality slips, and the team running both loses confidence in either way of working. That risk needs a plan built before the first phase starts, not one assembled halfway through it when availability is already falling.

A grocery chain sequencing its transformation this way ran into exactly this. The programme moved in a logical order: demand forecast augmentation first, then a shift of replenishment decision authority to the AI-assisted model once the forecast signal was reliable enough to trust. That dependency was correctly identified. You can't hand replenishment decisions to a model whose forecasts haven't been proven yet. What the programme hadn't designed was the gap state itself. Phase one ran six weeks over schedule. For those six weeks, the old replenishment process was partially retired because the team had already moved into retraining, and the AI signal wasn't yet reliable enough to act on. Availability deteriorated. The business fell back on manual override processes that had never been written into the continuity plan, because nobody had designed for a process that was neither fully old nor fully new.

The lesson from that phase got built into how every later phase of the programme was planned. The gap state stopped being treated as an acceptable side effect of a phase running late and started being treated as a risk with its own design requirements: what runs in parallel, what the cutover sequence actually is, how exceptions get handled when the new model isn't ready and the old model is being wound down regardless, and what the fallback position is when the sequence doesn't go to plan. That's the specific job of the Transition State Design (15e): it maps the transition explicitly rather than assuming a clean handover between two states that were only ever designed in the abstract. Section 11's Business Readiness Checklist (11g) gates each phase of rollout at the function level; the Transition State Design gives you the programme-level view of managing concurrent operations across all of them.

The other risk the timeline doesn't show

There's a second risk that concentrates in the same period and gets even less attention. Transformation programmes put a disproportionate amount of institutional knowledge into a small number of people: the technical leads who understand how the AI capability works, the programme lead holding the design threads together, and the business leaders who sat through target operating model design and understand what the target state is meant to look like in practice. During the transition, when the old model is being wound down and the new one isn't yet self-sustaining, that knowledge hasn't been distributed anywhere else. If one of those people leaves mid-programme, the transition's design logic leaves with them. Programmes that handle the transition period well document the design decisions, not just the target state, and build succession cover for the roles that would otherwise be irreplaceable at exactly the wrong moment.

Design the middle, not just the ends

The Target Operating Model Canvas (15b) gives you the current state and the target state. Neither one tells you how to move from one to the other without the business falling over in the process. That's a separate design exercise, and it needs the same attention as the target state itself: what runs in parallel, what triggers the cutover, what the fallback position is, and who holds the knowledge that makes the transition work.

For the full method, see Section 15: Designing for Transformation.

Design that middle stretch before you commit to a go-live date, not while you're living through it.