Paul Gething has spent twelve years in supply chain and transformation roles at a global industrial distributor, seven years in consultancy and ten years running operations before that. He currently leads the supply chain workstream of a multi-year transformation programme, including implementing SAP S/4HANA. This article draws on his experience to explore why the programmes that look healthiest are often the ones in most difficulty, how organisational readiness becomes evidence inside a business case rather than a workstream running alongside it, and which disagreements tend to surface far later than they should.
A programme that looked well governed
On one previous programme Paul describes, everything visible was in order. A steering group at executive committee level met regularly and received clear reporting. The slides said the right things. There were no escalations demanding attention and nothing in the governance pack that would cause a sponsor to ask a harder question than usual.
Below that, two groups were competing for control. The technology function and the business functions each believed they were running the initiative. On the surface the friction looked like ordinary disagreement about priorities, and underneath it had turned passive, with each side progressing work in its own area while the two of them stopped talking to each other in any meaningful way. The design taking shape would not have met the requirements, and would not have delivered the benefits the investment had been approved against.
The people who could see this were the ones closest to the work, and they were escalating. Nobody was acting on it. The reporting line ran through a technology project manager with weak business representation alongside, so the picture had already been tidied by the time it reached the people with the authority to change anything.
"They weren't in power."
Nobody lied, and the governance process worked exactly as it had been designed to work.
Noise is the health indicator
Ask Paul how he tells genuine organisational readiness from the version that only looks like it, and he does not reach for a framework. He reaches for the difference between what people say and what they do.
"It's actions and words."
What he looks for in leaders is accountability being demonstrated rather than expressed, decisions actually taken (and then stuck to), and a message reaching middle management, team leaders and shop floor with enough clarity that those people can repeat it. He checks that last part by asking them, rather than by asking the leaders who sent it. Further down he looks for people pulling the change rather than receiving it, contributing in workshops and requirements sessions, in his phrase being on the pitch.
Then there is the indicator that inverts most people's instinct. He watches the volume of open conversation about what is working and what is not, and treats a high volume as reassurance.
"One of the things that does kill some of these transformations is a lack of knowledge, a lack of conversation and a lack of openness. If it's too good to be true, it probably is."
A programme generating complaints, arguments and awkward feedback is a programme where people believe it is worth the effort of complaining. Silence can mean the same thing, but it more often means that people have concluded the conversation is not available to them, or that no one above is listening.
Why the quiet gets manufactured
Three mechanisms recur in Paul's accounts, and none of them requires anyone to behave badly.
The first is the one his near-miss illustrates. The people positioned to see a problem early are frequently the people with no authority to act on it, and the escalation route available to them runs through the person whose work is being questioned.
The second is that summaries have owners. A reporting line assembled around one function will produce an accurate summary of that function's view, and executive committees are the furthest point from the detail, receiving the most compressed version of it.
The third is the one he returns to most often, and it is about sponsors.
"We get sponsors who are put into these jobs without the right level of training and support, don't quite understand what their role is, and then when push comes to shove aren't really able to help and support or influence their peers to make changes and drive improvement."
This is a widely evidenced problem rather than a local one. The Project Management Institute has for several years identified actively engaged executive sponsorship as the single largest driver of project and programme success, while also finding that fewer than two-thirds of projects have an assigned executive sponsor at all. The gap between having a sponsor and having a sponsor equipped for the role is where a good deal of apparent readiness turns out to be hollow.
Head and hands
Paul's own framing for the distance between agreement and action is deliberately simple. He talks about the head and the hands.
"The head is about the why, the context, the rationale, the reason for something changing. And then the hands is about the what and the how and the who."
Most communication effort goes into the head. It is the part that suits slides, town halls and steering committees, and it is the part that produces agreement. The hands are where agreement either converts into different behaviour or quietly does not, and the work there is more mundane: scope people can hold in their minds, chunks of change small enough to be finished, and enough authority devolved that people can act without asking.
He is direct about one of the key failure modes, which is leaders making a change too complicated to land.
"If you can't run a team talk and get the essence of what you're doing over in three slides to the people on the ground, then you've got a problem. We make life complicated for ourselves sometimes."
The tension he acknowledges is that breaking a transformation into manageable pieces risks producing a collection of unrelated projects. His answer is a single agreed destination that the pieces, the building blocks, are continuously checked back against and each other. On one programme that destination was expressed as three clear and measurable outcomes: reduced cost, improved perfect order service and reduced working capital, with something close to thirty blocks of activity underneath, ranging from a large ERP platform migration down to critical people mindset changes and a solution to optimise how supplier documents were ingested. He describes his own job as building and maintaining the connections and dependencies between those blocks and the destination.
Making readiness checkable
Paul is clear that reading a room is necessary but insufficient. Alongside the qualitative judgement built from years of knowing how particular people respond to change, he wants evidence that can be examined by someone else.
The instruments he describes are unglamorous. Gate criteria with a people and change dimension added alongside the technical entry and exit criteria, so that moving to the next phase requires something about organisational readiness to be in place and signed off rather than assumed. A quality plan setting out an approach incorporating different and diverse perspectives, and what acceptance actually means, which he notes has been absent on more than one programme he has worked on. Peer review on key documents. Structured questions and surveys where the sample is large enough to be worth surveying.
The one most likely to be missing is the critical friend: someone from outside the programme, with no stake in its momentum, sitting on the steering group or a working group with a remit to ask uncomfortable questions. In his near-miss, that function was performed accidentally by an exec who had no involvement in the programme and no reason to protect its reporting.
Sensing it early, and stopping
The recovery is worth describing because of how ordinary it was. Paul was asked to look into something outside his own area. He worked with the exec and asked questions, read documents and sat in a couple of meetings, and concluded there was a problem. They put the programme's key leadership in a room more than once and established a safe psychological space. The relevant steering committee members were brought in. Roles, responsibilities, accountabilities and decision rights were reset explicitly using a structured approach, and the plan was replanned.
The part practitioners tend to skip in the retelling is that they stopped for a month.
"Rather than carrying on headlong into an abyss, let's stop, let's reset."
It was not comfortable afterwards. Behaviours slipped below the line, sometimes for months. The critical friend approach continued. The programme delivered what the business needed.
Readiness as evidence inside the case
Where this connects to the investment case is the part most likely to be treated as a separate exercise. Paul's position is that readiness work belongs inside the case rather than beside it.
"A good business case has some of that fed into it. This is where we are, this is where we want to move to, this is the plan, this is the cost, these are the benefits. You need that complete package."
Some of that readiness work can be done long before any money is committed: an initial impact assessment based on what is expected to change, an honest read on how the organisation makes and adheres to decisions and whether it generally collaborates or works in silos, and an assessment of whether the change is brownfield or greenfield, which he treats as a question about approach rather than ambition.
"It doesn't change what you're aiming for, but it might change how you approach it."
His examples are concrete. Automating an existing distribution centre is a materially different proposition from fitting out an empty purpose-built one. Redesigning processes onto a standard template is often easier than amending years of accumulated configuration to fit that template. The same is true of teams, where building a new one to deliver an outcome can be simpler than reshaping an existing one while it continues operating.
The evidence supports treating this as a costed variable rather than a footnote. Recent ISG research found that close to sixty per cent of SAP migrations run late and over budget, with organisations citing complex legacy landscapes, heavy customisation and unclean master data as the leading causes, and with underestimated complexity and unclear internal constraints named ahead of consulting fees. A case that has not priced its own brownfield conditions is optimistic rather than credible.
There is also the question of what size and structure of commitment to ask for. Paul has direct experience of different approaches: from a single request for multi-year funding in the tens of millions of pounds, often rejected as unfundable, through to a series of smaller requests for pilots that are hard to link together. For him, it is all about building confidence, in the solution, the stakeholders and the delivery capability. At a previous employer he worked with the middle-ground alternative: an overarching three-year envelope agreed up front, with an initial, more detailed request for funds to cover delivery of a global template and the first site deployment, including detailed work stream costing underneath it, a stated tolerance, further drawdown as the work progressed against measurable deliverables, and a continuing obligation to check back against the envelope's cost and benefit numbers. All are ways of handling the same tension: a number large enough to be attractive, a scope small enough to be deliverable yet still makes a difference, and an administrative overhead that stays manageable.
And underneath the numbers, something less quantifiable.
"Some of these numbers get approved because there's trust in individuals and the teams, not necessarily a belief that we'll save the £XX million stated in the business case."
The preference that arrives too late
The pattern Paul flags last is the one that undoes otherwise solid work. A senior stakeholder holds a settled view about which solution is right, formed from their own prior experience, and that view surfaces near the end of a process rather than near the beginning. In the case he describes, the preference ran against both the technology recommendation and the organisation's own strategy of reducing the number of vendors it supported.
His advice is to surface these positions deliberately and early, because a business case cannot be finalised while multiple options remain genuinely live, and because a stated preference is workable in a way that an unstated one is not.
"I would prefer this solution because of this. You can work and deal with that."
He is also unsentimental about where the difficulty originates.
"Some of the stress of that is self-imposed."
Which returns the argument to where it started. A programme where preferences, doubts and objections are being voiced and taken seriously is a programme where they can be resolved while resolution is still cheap.
"What you don't want is a senior champion who's in the passive but not committed camp and then pops it out as a surprise on the day."
Questions worth asking
- When did someone last tell you something about this programme that you did not want to hear, and what happened to them afterwards?
- Who in your organisation can see problems with this work but has no route to act on them?
- Does your sponsor understand what the role requires, and could they influence a peer who decided to obstruct this?
- If you asked three people on the shop floor what is changing and why, how similar would the three answers be?
- What has your case assumed about the condition of your existing processes, data and teams, and who tested that assumption?
- Which senior stakeholders hold a view about the answer that they have not yet said out loud?
- What would have to be true for you to recommend pausing or even stopping?