The Question Your Vendor Will Never Ask You
Most technology programs begin with the wrong assumption. Here’s how to find out if yours has.
Before a single contract is signed, before a vendor is selected, before a project team is formed — there is one question that determines whether your program will deliver lasting value or just a functioning system.
Are you doing a Transformation, or are you doing an Implementation?
These are not the same thing. They are not even close to the same thing. But in boardrooms and steering committees across every sector, they are treated as interchangeable — and that confusion is where value goes to die.
What Transformation Actually Is
Transformation is not a project. It does not close.Transformation begins with a different question entirely: What does this organisation need to become — and what will it take to get there and stay there?It requires understanding your business goals, vision, and mission before touching a single system. It requires designing the architecture — business processes, information flows, organisational capabilities — to support those goals. It requires a roadmap that sequences change across time, not just a Gantt chart that sequences tasks.But here is what makes transformation structurally different from implementation — and what most programs get wrong:
Transformation does not end at go-live. It accelerates after it.
Going live is not the destination. It is the moment when the real work begins. After go-live, the organisation must:
Manage the change and embed new behaviours — not just train users, but change how people actually work
Reinforce new culture and ways of operating across the organisation
Develop continuous improvement, governance, and support infrastructure
Consolidate what was gained and iterate to build new capabilities
None of that appears in a vendor’s statement of work. None of that is on the project closure checklist. None of that is measured by whether the software is functioning.
Transformation asks: Did we become what we needed to become — and are we sustaining it?Why Vendors and IT Teams Have a Simple View
This is not a criticism. It is a structural observation.
Vendors are paid to deliver software. Their commercial model is built around go-live. Their success metrics are uptime, configuration accuracy, and user adoption rates at handover. When the system works and the project closes, they have done their job. Everything that happens to your organisation after that is outside their contract and outside their interest.
IT teams, similarly, are oriented toward technical delivery. They think in system terms — integrations, infrastructure, data, security. These are necessary. They are not sufficient.
Neither the vendor nor the IT team is paid to ask: What does this organisation need to change about how it operates, and who is responsible for holding that change over time?
That question belongs to the executive sponsor. And in most programs, no one assigns it there — or if they do, no one defines what holding it actually looks like.
The Dangerous Middle Ground
Here is the pattern that appears in failing programs.
The executive sponsor approves a transformation. The language in the business case is transformation language — capability uplift, process improvement, cultural change. The board signs off on transformation-level investment.
But the program that gets designed and delivered is an implementation.
The vendor scopes for software delivery. The project team manages tasks and milestones. The steering committee reviews RAG status reports. The go-live happens. The project closes. The vendor leaves.
Twelve months later, the system is running — but the organisation operates almost exactly as it did before. The processes that were supposed to change haven’t changed. The governance that was supposed to improve hasn’t improved. The capabilities that were promised are theoretical, not operational.
The reports stayed green. The value never arrived.
This is not failure through incompetence. It is failure through misalignment — between what was approved and what was actually designed and governed.
The Question to Ask in Your Next Steering Committee
If you are a project sponsor, here is how to determine which program you are actually running — regardless of what the business case says.
Ask your project manager: What does success look like twelve months after go-live?
If the answer describes system performance — uptime, user counts, reports functioning — you are running an implementation.
If the answer describes organisational performance — how decisions are made, how the organisation operates differently, what capabilities now exist that didn’t before — you may be running a transformation.
Then ask: Who is responsible for the post-go-live work — the behaviour change, the governance, the continuous improvement — and what does their accountability look like?
If there is no clear answer, or if the answer is “the vendor will support us,” you have your diagnosis.
The vendor will not be there. That work is yours. The question is whether anyone designed it, resourced it, and built accountability around it — or whether everyone assumed it would happen on its own after the system went live.
It won’t.
What This Means for You as Sponsor
You approved an investment on the premise of transformation. Your job is to make sure that’s what you’re actually getting — not a well-configured system with transformation language in the business case.
That requires you to be able to answer three questions at any point in the program:
- Direction — Is the program still aligned to the organisational goals that justified the investment?
- Oversight — While the program is in flight, is the work happening as designed — or has it drifted into pure delivery mode?
- Stewardship — After go-live, who is actively protecting the value — governing the change, embedding the behaviours, building the capabilities?
If you cannot answer all three, you are not sponsoring a transformation. You are watching an implementation happen in transformation’s name.
That distinction will cost you — in value unrealised, in change unmade, and in a second program to do what the first one should have done.
