The textbook transformation exists: strategy agreed first, change management designed in advance, shadow managers placed across every key function, governance settled before day one, resources and competencies secured. It is also rare. Far more often, transformation starts as one narrow problem someone wanted solved — and grows because the first piece of work was done well.
The designed transformation is real, and it is the exception
There is a version of this work that everyone recognises from the literature. A strategy is set. A separate change strategy is written alongside it, because leadership has understood that the technical change and the human change are not the same programme. Shadow managers are placed in the key functions, so that the people running the business day to day are not also expected to redesign it in their spare hours. Governance is agreed before the first steering committee, not after the third escalation. Budgets are approved. The competencies required are identified honestly, and the gaps are bought in rather than wished away.
When an organisation arrives at that starting line, the work is genuinely easier. Not easy — but the arguments are about content rather than about whether anyone has the right to decide anything.
Most organisations do not arrive there. They arrive somewhere far more modest: a director who has a problem that is now visible enough to be embarrassing, a budget that stretches to a few months of external help, and no particular intention of launching a transformation at all. The transformation, if it happens, assembles itself afterwards.
I have spent most of my working life on that second path. Three engagements illustrate how it actually behaves.
A logistics brief can become seventeen projects without anyone deciding it should
A public-transport vehicle manufacturer brought me in as a consultant to look at a handful of specific logistics problems. Nothing strategic. Concrete operational irritations that someone wanted resolved.
The work went well enough that I was asked to lead one project. That project did not stay one project. Its scope touched material flows, which touched warehousing technology, which touched the building itself, which touched the WMS, which touched inventory sizing, health and safety, waste handling and site infrastructure. By the time the shape of it was clear, there were seventeen projects running under one umbrella — four of them large, the rest genuinely supporting rather than decorative.
Nobody in that organisation stood up one morning and announced a logistics transformation. It was moulded organically out of a consulting brief, and it eventually carried a production volume increase that the original brief had not mentioned. What made it hold together was not that it had been foreseen. It was that each new piece was attached to a structure that could take the weight.
Working on the symptom is how you find the system
A satellite communications equipment manufacturer engaged me to run an inventory reduction project. That is about as clean a brief as this profession offers: a number, a direction, a deadline.
It became clear quite quickly that working on the symptom of a system’s behaviour is not enough to change the behaviour. Inventory was where the problem surfaced, not where it lived. It lived in forecasting quality, in planning maturity, in how S&OP decisions were made and whether they were made at all, in the gap between what the planning organisation was accountable for and what it could actually influence.
So the project grew — into four substantial streams, at which point we stopped calling it a project and started calling it a programme. It acquired a name and a scope. Then, more or less in stride, it acquired a different name and a different scope, because the first framing had been outgrown rather than abandoned.
Scope that arrives in epics still needs a skeleton
That same programme woke up, repeatedly, in the form of epics with accumulating scope. There was a skeleton at the beginning — a governance structure, a reporting standard, a decision rhythm — but the content was built on top of it in an agile fashion, arriving faster than any plan would have predicted it.
This is the distinction that matters, and it is the one most often missed when people describe emergent work approvingly. Organic and chaotic are not synonyms. What separates them is whether something load-bearing was put in place early: who decides, at what cadence, on what evidence, and what happens when two streams want the same person in the same week. Improvise that as well, and you do not have an emergent transformation — you have a queue of unresolved arguments wearing programme branding.
The skeleton is cheap to build in month one and expensive to retrofit in month nine, which is the main practical reason to build it before you know what it will be carrying.
Sequence can do the work a roadmap was supposed to do
A commercial vehicle manufacturer pulled me in urgently as an interim manager to run warehousing and internal logistics. It was a gap-filling assignment with no strategic pretensions whatsoever. After eighteen months a permanent manager was found and we completed a handover, which in most engagement models is where the story ends.
Instead I was asked to build a logistics engineering function that had not previously existed. Then to run the internal PMO. Then, as project manager, to represent supply chain in major new product introductions and in plant industrialisation projects.
Read that as a list of assignments and it looks like a career accident. Read it as a sequence and it is something else: an organisation working through its most pressing constraints in the order they became binding. Stabilise the operation. Build the engineering capability that stops the same problems recurring. Install the governance that lets several efforts run at once. Then push supply chain upstream into the decisions that create the operational conditions in the first place.
That is a transformation. It was never named one, never carried a programme label, and never appeared on a three-year plan. It happened anyway, because each step was chosen against the constraint that was actually binding at the time rather than against a document written eighteen months earlier.
The absence of a three-year plan is not a governance failure
Executives are often quietly embarrassed about starting this way. There is no roadmap. The resourcing is partial. Nothing is scoped out to 2029. The assumption is that this represents a deficiency to be corrected before serious work can begin.
It usually does not. A three-year plan written before anyone understands the system produces confident sequencing of the wrong things, and it makes course correction feel like failure rather than learning. What genuinely matters at the outset is much smaller: a real problem worth solving, someone accountable for solving it, and a decision structure that can absorb the scope you have not discovered yet.
But this is exactly where the argument gets misused, and it is worth being precise. Accepting that you cannot plan three years ahead is not the same as accepting that you will work out the governance later. The first is intellectual honesty about how much you currently know. The second is a decision to improvise the one part of the system that does not tolerate improvisation — usually dressed up as pragmatism, occasionally as agility, and reliably paid for in month six when two stream leads discover they have been given contradictory priorities by different executives and neither of them has the standing to resolve it.
The distinction is between content and architecture. Content — which projects, in which order, delivering what — is genuinely discoverable, and pretending otherwise wastes months. Architecture — who decides, who is consulted, what is escalated, what remains reserved to the board, how competing priorities are settled, what evidence a decision requires — is not discoverable by doing. It is either agreed or it is contested, and organisations that leave it contested spend their transformation budget on the contest.
This is why a PMO charter matters more than its name suggests, and why the name is slightly unhelpful. You do not need a PMO to need one. What the document actually contains is a set of classical questions — the ones everyone knows and almost nobody asks out loud at the start of a transformation effort. Who owns this. What are they authorised to decide without asking. What must they escalate, and to whom, and how fast does that person have to answer. Which decisions belong to the owners and will never be delegated regardless of how inconvenient that becomes. What happens when a functional director declines to cooperate. What is this effort actually meant to change, and how will anyone know whether it did.
None of those questions require a roadmap to answer. All of them get harder to answer once work is under way and the answers have acquired winners and losers. Asking them at the point where the organisation is still deciding whether to act at all costs a couple of uncomfortable conversations. Asking them in month nine costs the programme.
Missing a roadmap is survivable. Missing clarity on who decides is not.
Buy for the second problem, not the first
The practical consequence sits on the buying side, and it is the reason I keep returning to these three cases.
If your entry point is likely to expand — and on this evidence it usually is — then selecting help purely on fit to the immediate brief is a false economy. The inventory specialist who cannot diagnose a planning organisation stops being useful at exactly the moment the work becomes interesting. The logistics consultant who cannot run a portfolio has to be replaced precisely when momentum matters most. Each replacement costs context, relationships and credibility, none of which appear on the invoice.
So when you engage external help, it is worth deliberately buying a wider competency range than the current problem requires. Not a bigger team — a broader person. Someone who can still be useful when the brief changes shape underneath them, because the brief will.
In my experience, that is also what turns a short assignment into a business relationship measured in years. Not the pitch, and not the framework. Work that was done well on something small, and the capacity to stay useful when it stopped being small.