← All Insights
6 min read

Why do so many transformation projects succeed on paper but fail in practice?

There is a particular kind of project outcome nobody talks about publicly. The delivery team hit the timeline. The budget was managed. The solution does exactly what the brief asked for. And six months later, the organisation is essentially where it started - the frontline still working harder than they should, still navigating the same friction, just with a newer system sitting on top of the same underlying problem.

Everyone involved calls it a success. And in a narrow sense, perhaps it was. But the people responsible for the work know - quietly - that something important wasn't solved. The gap between what was delivered and what was actually needed never quite closed.

This is the most common failure mode in digital transformation. Not the catastrophic go-live, not the blown budget, not the failed migration. Those failures are visible and teachable. The more insidious failure is the quiet, polite, well-managed delivery of the wrong answer - and the organisation that has to live with the consequences.

Why are briefs almost always written from inside the problem?

The brief was wrong. Not because the people who wrote it were incompetent - but because briefs are almost always written from inside the problem, and proximity creates a particular kind of blindness. When you are inside a problem long enough, the workarounds become the job. The symptoms become the disease. The queue that needs shortening becomes the thing to fix, when the real issue is three steps upstream in a process nobody has questioned in a decade.

I have sat in enough rooms to know this is rarely negligence. Most of the time it comes down to one of two things. Either the bandaid is genuinely all there is appetite for - smaller, digestible, affordable, and seen as some progress rather than none - and that is a legitimate position to be in. Or the organisation is simply too deep inside the problem to see they have missed it entirely. Both are rational responses to real constraints. Neither produces lasting change.

"The brief is almost never the real problem. It is usually visible just behind it - if someone is willing to look."

What does a vendor who answers the wrong brief actually cost you?

The dangerous assumption is that a vendor or technology partner will surface the real problem for you. Most will not - and it is worth being clear about why. It is not that they lack the capability. It is that they are commercially incentivised to answer the brief they are given. The RFP arrives, it describes a problem, they respond to that problem, everyone moves forward, the system gets built, and the problem persists. The project closes. The underlying issue quietly continues.

This dynamic plays out across industries and at every scale. Organisations buy platforms that are master of many things and genuinely excellent at only a few - and discover this only after the investment is made and the go-live is behind them. The cost is not just financial. Every failed or disappointing implementation leaves a stain in the minds of the executives who championed it. That stain makes the next attempt harder, the next conversation more defensive, and the next brief even more conservative than it should have been.

The market has a phrase for this kind of decision-making: nobody ever got fired for buying from the Gartner Magic Quadrant. That is true - and it explains a great deal about why so many organisations keep solving the same problem expensively and arriving at roughly the same place.

What is the real first question worth asking in any engagement?

The first value worth delivering in any engagement is not a solution. It is a better question. What are you actually trying to change? What does the business look like if this works? And - the one that tends to shift the direction of a room - if we solve exactly what you have described here, does the underlying problem actually go away?

That last question is harder than it sounds. Often the answer is no. And sometimes the people in the room already know it, and have been waiting for someone outside the organisation to say it out loud so they do not have to.

The most telling moment in any early engagement is not the answer to that question. It is how it lands. Some organisations lean in - there is genuine curiosity, a sense that the question has named something they have been circling for months. Others stiffen. The brief is the brief. The decision has been made. What they need is someone to execute it.

That second type has a phrase I have come to recognise in its many forms. It sounds like: that is interesting, but the business just wants us to paint it blue. Not said with malice - said with the particular exhaustion of someone who fought the fight internally and lost. The colour has been chosen. The room just needs a painter to paint over the cracks.

We do not take those engagements. Not because the work is not real - but because the foundation for genuine success is not there, and building on a bad foundation does not serve anyone well. The right outcome for both sides is to recognise that early, before significant time and money have been invested in the wrong direction.

How do you know when an organisation is genuinely ready to change?

Genuine readiness is not difficult to identify - but it is often mistaken for something else. It is not enthusiasm, and it is not urgency. Both of those can exist in an organisation that is firmly committed to solving the wrong problem. Genuine readiness is openness: the willingness to have the problem statement challenged before the brief is accepted, and the curiosity to ask what else might be possible rather than just what was asked for.

When that openness is present, the first conversation changes entirely. The questions become different. The room becomes collaborative rather than transactional. There is a sense that what is being designed together is more important than what was written in the document that initiated the process. That shift - from procurement to partnership - is the signal worth looking for.

It is also worth being honest about what genuine readiness is not. It is not an organisation that has allocated a budget. It is not a sponsor who nodded enthusiastically in a steering committee. And it is not a team that has written a detailed brief, because a detailed brief is often the clearest sign that the organisation has already decided what the answer looks like - which is precisely the constraint that produces the wrong outcome.

What is the difference between approval and commitment?

There is a condition almost nobody discusses when they talk about transformation readiness, and it sits at the leadership level. It is not budget. It is not technical maturity. It is not even organisational appetite, though that matters. It is whether leadership has moved from approval to commitment - and those are not the same thing.

"Approval gets projects started. Commitment is what finishes them."

The difference becomes visible the first time something gets hard. When the work surfaces a truth about an existing process that requires someone to absorb short-term disruption for long-term gain, or to acknowledge that a past decision did not deliver what was hoped - committed leadership moves through it. They make the call, they communicate it clearly, and the work continues. That is the environment in which transformation actually finishes and sticks.

Approval without commitment looks different. The project progresses well right up to the first real decision point - and then the support quietly contracts. Not through bad faith, but through the entirely human preference for preserving options and avoiding being the person who has to explain why something needs to change. The energy that was behind the project redirects. The team doing the work loses the air cover it needs. The original problem reasserts itself, and the new system gets used at a fraction of its potential.

The question worth asking at the start of any significant engagement is not whether there is sign-off. It is: when this gets hard - and it will - who is still standing behind it, and what are they genuinely prepared to absorb? If that question cannot be answered with confidence, the organisation may not be ready yet. Not permanently. Just currently. An honest partner says so.

What does a genuine transformation partner actually do differently?

The most meaningful engagement we never completed was one where we responded to a brief by telling the client that what they had asked for was not what they needed - and that what they actually needed required a readiness they had not yet built. Their leadership heard it, had the honesty to agree, and the project was deferred. They thanked us for it.

We do not see that as a failure. We see that as our approach working exactly as it should.

It only works, though, if the partner is positioned - commercially and culturally - to say uncomfortable things without flinching. Not transactional. Not carrying a product that needs shifting. Not measuring success by whether the engagement was won, but by whether the outcome was genuinely worth pursuing. That impartiality is not just a nice quality to have in a partner. In complex, regulated environments where the cost of solving the wrong problem is high, it is the most important thing on the table.

Most organisations have never been in a room with a partner like that. Which is precisely why, when they find one, the relationship tends to last - and why the work that comes from it tends to actually change something.

Every engagement we take starts with the same intent: understand the real problem before we touch the solution. Sometimes that means challenging the brief. Sometimes it means slowing down before speeding up. And occasionally it means telling someone they are not ready yet. That is not a positioning statement. It is just how the best work gets done.

Frequently asked questions

Why do digital transformation projects fail even when they deliver on time and on budget?

Most transformation projects that underdeliver did so because the brief was wrong - not the execution. When organisations write their own briefs from inside a problem, proximity creates blindness. The symptoms get addressed, but the underlying cause is not touched. The result is a technically successful project that changes nothing of significance.

What is the difference between a transformation partner and a solution vendor?

A vendor answers the brief they are given, because their commercial model rewards them for doing so. A transformation partner challenges the brief before accepting it - interrogating the problem statement, questioning whether the proposed solution addresses the real issue, and sometimes advising that the organisation is not yet ready to proceed. That impartiality is only possible if the partner is not commercially dependent on a specific product or platform outcome.

What does organisational readiness for transformation actually mean?

Readiness is not about budget or technical maturity - it is about whether leadership has moved from approval to commitment. Approval gets projects started. Commitment is what absorbs the difficult moments: the uncomfortable truths, the decisions that require acknowledging past mistakes, the short-term disruption required for long-term gain. Without genuine commitment at the leadership level, transformation stalls at the first real decision point.

How do you identify the right problem to solve before starting a transformation project?

The most useful question in any early engagement is: if we solve exactly what has been described here, does the underlying problem go away? Often the answer is no - and the people in the room already know it. The value of an external partner is the structural distance to ask questions the organisation has stopped being able to ask itself, because proximity has made those questions invisible.

How does the Decision Pyramid relate to solving the right problem?

The Decision Pyramid describes how organisations invest most of their effort at the bottom - data gathering, document processing, cross-referencing - while the actual decision at the top receives a fraction of the attention. Solving the right problem means understanding which layer the real issue lives in. Many briefs address effort problems with effort solutions, when the real opportunity is to rethink the structure entirely.

Next in this series
Decision vs Work Automation - and Why the Difference Matters
AI is genuinely excellent at compressing work. But automating work and automating decisions are fundamentally different capabilities - and most organisations are using the same brush for both.
Read the next article →
We find the problem worth solving. Every engagement we take starts with a challenge to the brief - not because we are difficult, but because solving the right problem is the only thing that delivers lasting value.
We own the outcome. We are not transactional. We measure success by whether the problem was genuinely solved - not whether the project was closed.