The riskiest moment in a planning transformation isn't the go-live. It's earlier than that, and quieter. It's the period between a business recognising that something needs to change and the moment it commits to a direction. That gap is where most transformations are won or lost, and it's the part of the process that gets the least structured attention.
This observation came through clearly at BestPractice.Club's Spring 2026 in-person meeting, where senior supply chain and planning leaders spent a day working through live transformation decisions with practitioners who had navigated similar ones. It wasn't a new idea to anyone in the room. What was striking was how consistently the same pattern surfaced across very different organisations, sectors and starting points.
The gap has a predictable shape. A trigger arrives, usually a burning platform, a mandate from leadership to do something with AI, or a growing recognition that the current state can't sustain the next phase of the business. The organisation starts looking: information gathering, vendor conversations, demos. That process costs little in money and carries almost no formal commitment, so it feels safe. Then something shifts. Consultants are engaged. An RFP goes out. At that point the cost and the commitment both escalate sharply, and many of the structural questions that would have been cheap to resolve earlier are now surfacing in conditions where changing course is expensive.
What sits between the trigger and the commitment is the gap. The question is whether it gets used.
The gap is not a waiting room
The most common mistake is treating the gap as empty time, a period of not-yet-decided that will resolve itself once enough information has been gathered. In practice the gap fills up on its own if you don't structure it deliberately, usually with vendor momentum, recency bias towards whatever the last demo showed, and the particular kind of urgency that comes from having started the process without being clear about what you're trying to achieve.
Organisations that navigate this phase well treat it as a working phase with a specific job: to answer the questions that are genuinely cheap to answer now and genuinely expensive to discover later. Not every question. The ones that, left unresolved, become the fault lines that open up during implementation.
Five questions come up consistently across the conversations we've had with practitioners over the past several years. They're not a framework and they're not a checklist. They're more like tests of whether you're actually ready to move or just ready to stop feeling uncertain.
Does the business genuinely want the degree of change this requires?
This is the question nobody asks directly, and the one that decides most of what follows. It's possible to have a plausible case, a willing sponsor, and a reasonable budget, and still have a business that will resist the change once it becomes real. The resistance isn't always visible in advance. It shows up when the operating model design starts to touch incentive structures, when centralisation conversations reach people who've run their own patch for years, when the data governance work starts creating accountability that wasn't there before.
The appetite question isn't about executive support in principle. Most transformations have that. It's about whether the organisation is prepared to accept the specific degree of disruption that this type of change actually requires, not an idealised version of it.
One of the more useful diagnostics is to describe the operating model implications concretely to the people who will have to live in it, and watch what happens. Not in a formal workshop with slides, but in working conversations where the trade-offs are made specific. If the response is discomfort followed by engagement, the appetite is probably there. If the response is reframing toward a version of change that doesn't actually disrupt anything, that's the signal that the business isn't ready, regardless of what it says in the steering committee.
Are we solving the right problem?
This sounds obvious and is consistently underinvested. The trigger that starts a transformation programme is rarely a precise diagnosis. A burning platform creates urgency without necessarily creating clarity. Leadership pressure to act on AI creates direction without necessarily creating a problem statement. The information-gathering phase, demos and vendor conversations especially, tends to sharpen the solution picture rather than the problem picture, because that's what those conversations are designed to do.
Getting to a specific, agreed account of what's actually broken, why it matters, and what would be different if it were fixed is harder than it sounds and more valuable than most organisations realise. The Dan Smith piece on planning transformation at Coty describes what this looks like in practice: fifteen specific operational problems defined before a vendor was selected, each one a concrete gap rather than an aspiration. That level of specificity is unusual. It's also what made the subsequent investment defensible when it came under scrutiny.
What does the operating model need to deliver before we choose tools to support it?
The sequence matters more than almost anything else in this phase. Tools chosen before the operating model is defined tend to shape the operating model, which is almost always the wrong way round. The tool reflects a particular set of assumptions about how planning decisions will be made, who will make them, and what information they'll need. If those assumptions haven't been worked out by the organisation first, the tool's assumptions fill the gap by default.
This is a different argument from "define requirements before selecting a system," which is standard advice and frequently followed. It's about something prior to requirements: the decision rights, the governance structure, the reporting lines and accountabilities that determine how the planning function will actually operate. You can define requirements in reasonable detail and still not have resolved whether demand planning sits centrally or locally, whether the S&OP process has real decision authority or is a reporting forum, or who is accountable when the plan and the outcome diverge.
Those structural questions have answers that follow from the operating model design. They don't have answers that follow from vendor demonstrations. Addressing them in the gap, while the field is still open, is one of the things that distinguishes transformations that work from those that are still reworking the same problems three years after go-live.
The resilience-is-designed-through-structure piece explores what this looks like across large, complex industrial organisations. The pattern it describes, operating model first, then capability design, then technology, is the same sequence that surfaces consistently in the practitioner conversations that inform BestPractice.Club's work.
Have we honestly assessed our maturity, or just our ambition?
One of the more expensive recurring mistakes in planning transformation is buying capability the organisation isn't ready to use. A platform chosen for its advanced forecasting functionality that requires clean, integrated data across the network assumes a data foundation that most organisations are still building. An AI-driven planning tool that requires planners to trust system recommendations assumes a level of process maturity and change readiness that takes time to develop.
The Gartner quadrant is a useful illustration of the problem. Several practitioners at the Spring meeting described the same pattern: time pressure, limited bandwidth to do thorough groundwork, and a pull toward the top-right quadrant because it felt defensible. The result, in some cases, was an implementation that worked technically but couldn't be absorbed operationally — the maturity journey that should have come before the platform decision was instead attempted in parallel with it, at much higher cost and under much more pressure.
Research from McKinsey and others on digital transformation outcomes consistently finds that readiness assessment is among the most underdone elements of transformation planning. The organisations that get this right tend to be honest about the gap between their current state and the state required to get value from the investment they're considering, and they treat closing that gap as a design constraint, not a post-implementation problem.
Would this plan survive scrutiny from someone with no commercial interest in the answer?
By the time a business reaches the RFP stage, the people with the most detailed knowledge of the plan tend to have a stake in it. The internal team has invested months of work. The vendor has invested in the relationship. The consultant has shaped the scope. None of this is bad faith, but it does mean that the plan rarely gets pressure-tested by someone who brings both relevant experience and genuine independence.
The gap is the right time to do that. Not through a formal review process, but through the kind of working conversation that surfaces the assumptions that haven't been tested, the dependencies that haven't been acknowledged, and the failure modes that have been mentally filed under "we'll deal with that if it comes up." Practitioners who've made similar decisions in comparable contexts, with no commercial stake in what you decide, are the most useful source of that challenge. They'll ask the questions that internal advocates and vendor representatives won't.
This is the specific function that peer review serves in a transformation decision: not validation, but stress-testing. And it's most valuable in the gap, before commitment, when the cost of finding a problem is low and the cost of missing one is high.
What using the gap well actually looks like
The organisations that navigate this phase effectively tend to share a few recognisable characteristics. They resist the pull toward vendor engagement before the problem is defined. They invest real time in the operating model question before the requirements document is written. They treat maturity honestly as a design input rather than a barrier to be managed. And they find ways to get genuine outside-in challenge before they commit, not after.
None of this is guaranteed to produce a good outcome. Transformation decisions are made under real constraints: time pressure, limited internal bandwidth, competing priorities, and stakeholders who've already formed views. The gap rarely offers ideal conditions. But the organisations that use it well tend to arrive at their commitment decision with far fewer untested assumptions than those that treat it as a passage to get through quickly.
There's a pattern we've observed across more than a thousand recorded conversations with supply chain and operations leaders over the past six years. The ones who describe their transformation as having gone well, or at least as having gone the way they understood it would, almost always did meaningful work in this phase. The ones describing painful post-implementation rework, loss of credibility, or a business case that was effectively reverse-engineered to justify a decision already made, tend to describe having moved through this phase quickly, under pressure, without structured support.
The gap doesn't have to be long. It has to be used.
This article draws on discussion at BestPractice.Club's Spring 2026 in-person meeting on 29 April in London, and on patterns from BestPractice.Club's ongoing programme of practitioner conversations. Participants in the meeting discussion are not named individually in this article.
If you're currently in this phase of a planning transformation decision, BestPractice.Club's upcoming sessions are designed for exactly this stage. Details at bestpractice.club/upcoming-sessions.