Why the Questions That Matter Most in a Planning Transformation Don't Get Answered Well From Inside
There's a particular kind of confidence that builds inside a transformation programme as it gathers momentum. The steering group is meeting regularly. The vendor shortlist is taking shape. The internal team has done significant work and knows the material well. That confidence isn't false, exactly. It's just that it tends to be concentrated in the answers to the wrong questions.
The questions that actually decide whether a transformation succeeds or fails are mostly answered earlier, in the phase before formal commitment, and mostly answered by the people with the most at stake in getting them right. Which is, structurally, one of the least reliable conditions for arriving at an honest answer.
This isn't a criticism of internal teams. It's an observation about how organisations work. The sponsor has a stake in the programme proceeding. The planning team's sense of what's possible is shaped by the constraints of the system they're already running. The IT team has a preferred architecture and a view of integration complexity based on what they've already built. The finance team is working from assumptions about value that were formed before the problem was fully defined. None of this is bad faith. It's the normal condition of being inside a problem rather than looking at it from outside.
The consequence is that three questions in particular, the ones that most reliably determine whether a transformation works, tend to get answered in ways that reflect the organisation's existing assumptions rather than a clear-eyed assessment of what's actually required.
Does the business genuinely want what this transformation actually involves?
This is the question that gets substituted most often. What gets answered instead is a related but different question: does the business want the idea of transformation, the capability improvement, the competitive positioning, the AI story for the board? The answer to that is almost always yes. The appetite for the specific degree of operational disruption that the transformation actually requires is a different matter, and it's rarely tested directly before commitment.
Simon Geale, Executive Vice President at Proxima, describes this as the designed absorption problem. A business can articulate a plausible transformation vision and still lack the genuine absorptive capacity to execute it, not because the people aren't capable but because the organisation hasn't been designed to take that degree of change on board while continuing to operate. The gap between what a business says it wants and what it's actually structured to absorb is one of the most consistent sources of mid-programme failure, and it almost never shows up in a readiness assessment produced internally.
Part of the reason is that appetite assessments tend to happen in conditions that suppress honest answers. A formal workshop with senior stakeholders present produces socially acceptable responses. A steering committee where the programme already has momentum produces responses shaped by that momentum. The people most likely to give an honest account of whether the organisation is actually ready for the change being proposed are often not the ones whose views get systematically captured.
Alex Johnson, Chief Supply Chain and Business Transformation Officer at Clinigen, describes the practical version of this problem. Getting leadership team alignment on the operating model took significant time before the formal transformation journey could begin in earnest. That wasn't delay. It was the appetite question being answered properly, through working conversations and tangible decisions rather than through workshop outputs. The difference, in his experience, is between a transformation that has a coalition genuinely willing to accept what change requires and one that has stakeholders who've agreed in principle to something they haven't fully imagined in practice.
The appetite question doesn't have a clean diagnostic. But there is a reasonable test: describe the operating model implications concretely to the people who will have to live in them, and notice whether the response is discomfort followed by engagement or reframing toward a version of change that doesn't actually disrupt anything. The latter is the signal that the appetite question hasn't been honestly answered, regardless of what the governance documentation says.
What does the operating model need to deliver, and has it been designed before or after choosing the tools?
The sequence here is where most transformations make their most expensive mistake, and it's a mistake that's almost impossible to see clearly from inside the programme. Tools get selected. The operating model gets defined around them. The process looks like operating model design but it's actually operating model rationalisation, making the organisation fit the tool's assumptions rather than the other way round.
This happens for understandable reasons. Operating model design is hard, contentious and slow. Vendor demonstrations are concrete, engaging and fast. The shortlist gives a programme visible momentum that an operating model workshop doesn't. By the time the operating model work happens in earnest, the tool's architecture has already established the frame within which it takes place.
Chris Bassano, formerly Group Supply Chain Director at Standard Industries and BMI Group, ran supply chain transformations at Rolls Royce Marine and then across 120 factories and 48 ERP systems. He describes the operating model question as the thing that determines whether everything else is even possible. At Rolls Royce, the transformation from independent vertically integrated sites to a functional matrix organisation took eighteen months and required a fundamental restructuring of accountabilities before any system change was attempted. The system change came after, not because of a principled commitment to sequence, but because the operating model question had to be answered first for the capability change to have anywhere to land. The full account of that transformation is worth reading for anyone working through similar structural decisions.
The interesting detail in his account is what made that sequencing possible: a deliberate decision to bring in an HR director as a genuine co-leader rather than a support function. That partnership created accountability for the operating model design that wasn't solely owned by the supply chain function and therefore wasn't solely shaped by its existing assumptions. The outside-in element in that case wasn't an external consultant. It was a functional colleague whose vantage point was fundamentally different from the people who'd built the system being changed.
The operating model question also has a component that rarely surfaces without external pressure: decision rights. Not at the level of a RACI matrix, which most programmes produce, but at the level of who actually makes which call when the plan and the commercial reality diverge. James Moffatt, Practice Leader at Baringa, describes this as the central unresolved tension in most supply chain organisations: the people who understand the operational detail well enough to make good decisions don't have the authority to make them, and the people who have the authority don't have the operational proximity to use it well. An operating model that doesn't resolve that tension produces exactly the same dysfunction after implementation as before it, regardless of what the technology can theoretically do.
This connects directly to the observation in the strategy drift piece that business strategy and supply chain strategy tend to separate not through disagreement but through assumption: each function believes the other has resolved questions that neither has actually addressed. Decision rights sit at the intersection of that drift, and they don't get resolved by the tools.
Are we honest about our maturity, or just our ambition?
Of the three questions, this is the one where the gap between internal assessment and external reality tends to be widest. Organisations benchmark their maturity against their own prior state and against the vague general standard of their peer group rather than against what the specific investment they're considering actually requires. The result is a maturity assessment that confirms the programme is viable rather than one that tests whether it is.
The Gartner quadrant dynamic is the most visible version of this. Several practitioners at BestPractice.Club's Spring 2026 meeting described the same pattern independently: time pressure, limited bandwidth and a pull toward the top-right quadrant because it felt defensible rather than because it reflected a clear-eyed assessment of what the organisation could absorb. The implementation that followed worked technically but couldn't be absorbed operationally because the maturity journey that should have preceded the platform decision was instead attempted in parallel with it, at higher cost and under significantly more pressure.
The deeper version of the problem is what might be called the normalisation of complexity. Internal teams, by definition, have adapted to the constraints of the environment they're operating in. The 48 ERP systems at BMI were not experienced internally as an extraordinary data challenge. They were experienced as the normal condition of the business, to be worked around rather than resolved. It took an external vantage point to make the true scale of the problem visible as a design constraint rather than a background condition.
Research consistently finds that organisations significantly overestimate their readiness for transformation at the point of commitment. The gap between stated readiness and operational reality is widest precisely in the areas that are hardest to assess from inside: data quality, process discipline, change absorption capacity and decision-making speed. These aren't things that show up clearly in an internally produced readiness report. They show up in the first six months of implementation.
This is where the parallel with scientific method is most useful. A well-functioning internal team that follows every step of a rigorous process can still arrive at a collectively wrong answer if everyone involved shares the same adapted assumptions about what normal looks like. The problem isn't incompetence. It's that the team is testing a hypothesis using evidence gathered from inside the conditions the hypothesis is about. The confirming evidence accumulates naturally. The disconfirming evidence requires deliberate effort to find, because it tends to be invisible from inside the system.
The Dan Smith piece on end-to-end transformation describes what honest maturity assessment looks like in practice: fifteen specific operational problems defined before a vendor was selected, each one tested against the organisation's actual capability rather than its aspirational state. That level of discipline is unusual precisely because it requires the team to actively look for evidence that the plan is wrong, not just evidence that it's right.
The organisations that get this right tend to share a particular disposition: they treat their maturity assessment as a hypothesis to be tested rather than a conclusion to be documented. That disposition is harder to manufacture internally than it sounds, because the conditions of a live programme create structural pressure toward confirmation. The most reliable way to create the conditions for genuine falsification is to bring in someone who has no stake in the answer being yes.
What this means in practice
None of this is an argument that internal teams can't navigate these questions well. Some do. The ones that tend to manage it share a few recognisable characteristics: they slow down deliberately at the point where momentum is building fastest, they find ways to hear from people whose vantage point is genuinely different from their own, and they treat uncomfortable findings as more valuable than comfortable ones rather than as obstacles to be managed.
That last point matters more than it sounds, and it's harder than it looks. The instinct in most transformation programmes, when an external challenge surfaces a problem with the plan, is to find a way to accommodate it within the existing direction rather than to take it seriously as a reason to reconsider. The scientific method runs the other way: a finding that challenges the hypothesis is more informative than one that confirms it, and a programme that can't be falsified by the evidence available probably isn't being tested rigorously enough.
There's also a psychological dimension that makes this harder than the epistemological one. By the time a programme has a steering group and a shortlist, the change champion has formed a view and, often without quite realising it, made implicit commitments. At that point, an outside-in challenge to the plan doesn't just feel like new information. It can feel like a verdict on their judgment. The peer who knows the domain well enough to give a useful challenge is also the person whose challenge lands closest to home. That's part of why the disconfirming evidence tends not to get sought out: it isn't just invisible from inside the system, it's uncomfortable to look for.
The question worth sitting with, before the RFP goes out and the commitment escalates, is a simple one: who in this process has both the relevant experience and the genuine freedom to tell us we're wrong? If the honest answer is nobody, that's the gap that needs filling before anything else."
This article draws on discussion at BestPractice.Club's Spring 2026 in-person meeting on 29 April in London, where senior supply chain and planning leaders discussed operating model design, transformation sequencing and the conditions for sustainable change. Contributions from Simon Geale (Proxima), Alex Johnson (Clinigen), Chris Bassano (formerly Standard Industries / BMI) and James Moffatt (Baringa) are drawn from the panel discussion.
This is the second in a series exploring what the gap between knowing change is needed and committing to a direction actually contains. The first article is The Gap That Decides Whether Planning Transformations Succeed. The next piece in the series looks at the operating model question specifically: what it contains, why it gets answered in the wrong sequence, and what the organisations that get it right tend to do differently.