Vague Ambitions Produce Precise Disappointments
What complex change programmes consistently get wrong and what the pattern actually looks like
The ambition is real. The investment is serious. The people involved are capable. And still, two years later, the organisation is not where it wanted to be, and nobody can quite explain why.
Estimates in the change management literature often place failure rates around 60–70 percent, though these figures vary considerably by context and methodology. Consultant and survey-based data suggest the figure may be higher for complex and ambitious programmes (BCG Henderson Institute, 2024; Errida and Lotfi, 2021).
Programmes tend to fail when they begin without a concrete picture of success, drift when that picture is not maintained, and reach their users too late. This article examines each failure in sequence and describes what organisations that navigate this well actually do differently.
These observations come from working inside large organisations on process change, performance management, and operating model design. The patterns described here are not exceptions. They are the rule.
The need that was never properly understood
Most programmes start with a solution rather than a need. The question that gets skipped, what exactly needs to be different, for whom, and how would we know determines whether the programme will succeed.
Most change projects tend to start with a solution. A new system, a restructured function, a process redesign. The decision to act comes before the need has been properly examined.
Heifetz and Linsky identify this as one of the most reliable predictors of failure: organisations apply technical solutions to adaptive problems (Heifetz and Linsky, 2002). Technical problems have known solutions. Adaptive challenges require people to change how they think or work and no technical implementation resolves them. The result is predictable: superficial changes that do not hold, resistance labelled as non-compliance, and change fatigue that compounds.
I have sat in many rooms where a programme was designed around objectives nobody could translate into operational terms. “Improve efficiency.” “Strengthen governance.” These are directions, not destinations. They tell you which way to walk but not when you have arrived.
Studies of large-scale transformations indicate that organisations which clearly defined roles and maintained transparent progress reporting reported substantially higher success rates than those that did not (Vayyavur, 2015). The gap between a direction and a destination is not just a planning problem. It is where most programmes get lost.
That question cannot be answered without a picture concrete enough to navigate by.
The picture that needs to exist before the work begins
A vision is not enough. What a programme needs is a description concrete enough that two people would agree on whether a given situation matches it. Without that, consensus is an illusion.
Before any design work starts, one thing needs to exist. A concrete picture of what the organisation looks like when the change has actually worked. Not a vision. Not principles. A description specific enough that two people reading it would agree on whether a given situation matches it or not.
What decisions get made differently? By whom? What does a controller do on a Monday morning that they cannot do today? What stops happening that currently consumes time and creates friction?
Vague ambitions produce precise disappointments.
This concreteness feels uncomfortable early. It forces choices before people feel ready. It surfaces disagreements that are easier to defer. And it gets skipped for exactly that reason.
A workshop is scheduled. The facilitator has a deadline. The group brainstorms. The output looks like clarity and functions like ambiguity. Two weeks later, different people are designing toward different pictures and nobody has noticed.
In line with Kotter’s argument that a vision must be concrete enough to guide individual decisions, the absence of an operationalised end state is one of the most common points at which programmes lose direction (Kotter, 1996). Armenakis and Harris show that readiness for change depends on recipients understanding a clearly defined future state — where this is vague, commitment does not follow (Armenakis and Harris, 2002). The disagreements that surface when you describe the end state concretely are the same ones that will derail implementation later. Surfacing them early costs a conversation. Surfacing them during execution costs months.
The model below maps this across the four phases where these decisions are made — and where they are most often deferred (see Figure 1).
Having a picture is necessary. Keeping it honest throughout the work is harder.
The comparison that never gets made
Programmes that measure activity rather than direction drift without noticing. Parked exceptions become permanent features. The solution goes live while the problem it was supposed to solve quietly remains.
Even with reasonable clarity at the start, something tends to go wrong in the middle. Milestones get hit. Budgets get tracked. Status reports get produced. What does not get produced is a regular, honest comparison between where the programme is heading and the concrete picture of where it was supposed to go.
The mechanism is gradual. A complex process has too many edge cases to resolve before the deadline, so the exceptions get parked. Later arrives and the exceptions have become permanent features of the new solution, each requiring manual handling the design was supposed to eliminate.
Research on implementation fidelity indicates that drift from the intended design is a common pattern when programmes do not actively monitor what is being delivered against what was planned (Carroll et al., 2007). Research on process workarounds shows that these deviations are goal-driven adaptations to constraints the formal process cannot accommodate (Alter, 2014). When parked exceptions are absorbed into the final solution, temporary workarounds become structural. The distance from original intent grows until admitting it would require acknowledging the programme has been heading the wrong way. That admission is expensive. So it does not get made.
Understanding why programmes drift is not enough. The more immediate question is why they slow down before the drift becomes visible.
Why things slow down
Slowdown is rarely about resistance or resources. It is usually about clarity. When people do not understand the problem well enough to know what a good next step looks like, speed is not the answer.
Speed is not the answer. Clarity is.
One of the most common reasons programmes lose momentum is simpler and harder to admit than resistance or resources. Nobody quite understands the problem, or how to approach it. Understanding a problem well enough to discuss it is not the same as understanding it well enough to act on it.
It also shows up in a specific pattern most programme managers recognise. A key stakeholder is senior enough to matter and busy enough that their calendar is always full. The planning cycle came up. The forecast work got in the way. Together these mean the person whose input is needed has not been in the room for six weeks, and the programme has been working around their absence rather than addressing it.
This is rarely a commitment problem. Studies of BPR projects suggest that competing priorities and poor planning are recurring factors in stakeholder disengagement, more often than outright unwillingness (Bashein and Markus, 1994). While this evidence comes from a BPR context, the pattern is consistent with broader observations on transformation programmes. When involvement is not concrete enough to compete with other demands, it will not compete.
When a programme slows without obvious cause, the right question is not about pace or commitment. It is whether the people doing the work have a clear enough picture of the problem to know what a good next step looks like.
Working at the right level, all the time
Strategy, process design, and daily operations require different conversations. When these levels get mixed, people leave the room thinking they agreed when they did not. Keeping them connected is a discipline, not a structure.
Complex change happens simultaneously at the level of strategy, process design, and daily operations. These levels require different conversations, different language, and different decisions. When they get mixed, people leave the room thinking they agreed when they did not.
A steering group agrees the new process must “support the business.” Three weeks later, the operations team designs approval workflows requiring four sign-offs for every purchase order. Nobody connects the two. The strategic decision was made at one level. Its operational consequence was designed at another. Nobody was in the room for both.
Research on multi-level change indicates that failure to translate across organisational levels is a recurring cause of implementation breakdown (Whelan-Berry and Gordon, 2000). Navigating complexity requires that everyone knows, at any given moment, which level they are working at and how it connects to the others. Not as a one-time orientation, but as a continuous habit.
When this breaks down the symptoms are familiar. Senior leaders believe the change is further along than it is. Operational teams solve problems that strategic decisions have already made irrelevant. Middle layers absorb the cost of the gap between them.
Keeping the levels connected is not a structural problem. No governance model solves it. It is a discipline, practiced in individual conversations, that has to be built into how the programme works from the beginning.
Keeping levels connected is a structural discipline. But the most damaging failures in complex change are not structural. They are human.
The human side that gets abstracted away
Abstract warnings create alibis, not readiness. Communication mantras fill silence without providing stability. Late handovers delegate the hardest work without the authority to do it. All three are predictable and all three are preventable.
Change management appears in most large programmes. What it rarely contains is the same concreteness the rest of the programme lacks.
Many programmes warn people that things will get harder before they get better. When that warning is not connected to what specifically will be harder, for whom, and when, it does not create readiness. It creates an alibi. People can prepare for specific difficulty. They cannot prepare for difficulty in general.
Then there is the communication mantra. At a point where uncertainty is genuine, the response becomes a repeated message: we do not know yet, but we will communicate when we do. Said once, this is honest. Said throughout a project, it tells people nobody is steering. Weick’s work on enacted sensemaking shows why: in conditions of uncertainty, people actively construct meaning from whatever cues are available, and those constructions drive behaviour (Weick, 1988). Communications that fail to provide stable reference points leave employees filling gaps with interpretations that consistently run more negative than the reality (Barr et al., 1992).
The third failure is the late handover. Users are involved too little for too long, then too much too late. A general training session before go-live is not change management. It is notification. Academic studies and practitioner research both indicate that lack of employee participation poses risks comparable to inadequate project definition (Chatzoglou et al., 2016; Prosci, 2024). People do not resist change because they cannot handle it. They resist it when asked to carry a weight they were not part of shaping.
Bringing people in earlier does not slow programmes down. It removes the resistance that slows them down later.
The figure below maps when each trap typically strikes — and what connects them (see Figure 2).
Each trap is preventable. But prevention requires more than awareness — it requires someone actively maintaining orientation throughout the programme.
Staying oriented during the work
Orientation requires more than good intentions. It requires a shared reference point concrete enough to use in real time, and someone with the mandate to ask the question organisations find most uncomfortable: are we still going where we said we were going?
Keeping a programme oriented toward its original purpose requires something more deliberate than good intentions.
It requires the concrete end state to be visible and shared throughout — not just at the beginning. Every significant decision tested against it. Not “does this seem reasonable” but “does this move us toward the specific picture we agreed on.”
A programme director in a finance transformation described it this way: every week we reviewed what had been delivered. Nobody reviewed whether it was still pointing at the same destination. By the time we checked, six months of work had quietly moved the target.
It requires someone with the mandate and overview to ask the question organisations find most uncomfortable. Are we still going where we said we were going, or have we quietly started going somewhere else.
What this looks like in practice
The organisations that navigate complex change well invest disproportionate time at the beginning, maintain a living picture of the end state, and treat slowdown as a signal to investigate rather than a problem to manage around.
The organisations I have seen navigate this well share a few habits.
They invest time at the beginning that feels disproportionate. Conversations about what the end state means in concrete operational terms, before any design work begins. Frustrating conversations that surface disagreements and prevent the larger, more expensive slowdowns later.
They maintain a living description of the target state. Updated when genuine learning changes the picture. Held firm when pressure is trying to lower ambition.
They build regular comparison into the programme rhythm. Not just “are we on track” but “on track toward what, and how do we know.”
They make abstraction levels explicit in every significant conversation and treat a mismatch as something to resolve, not work around.
They involve people closest to the work early enough that their knowledge shapes the design, not so late that their resistance shapes the outcome.
Not everyone reading this has the mandate to change how a programme is designed. But anyone involved can ask the question that matters most: do we have a concrete enough picture of where we are going that I would know if we started moving away from it? If the answer is no, that question is worth raising — regardless of where you sit.
The question worth asking before the next programme starts
Most of what goes wrong in complex change is not inevitable. It is the predictable consequence of skipping questions that felt uncomfortable at the start.
Change is hard. Organisations are complex. Resistance is real.
But a surprising share of the difficulty comes not from the complexity of the change itself. It comes from never having established a concrete enough picture of what the change is actually for, and never maintaining that picture clearly enough to navigate by.
Before the next programme starts, one question is worth sitting with longer than feels comfortable.
If this works, what exactly will be different, and how will we know?
If that question does not have a concrete answer, everything built on top of it is built on assumption. And assumption is not a foundation. It is a reason to start over.
References
Alter, S. (2014). Theory of workarounds. Communications of the Association for Information Systems, 34, 1041-1066.
Armenakis, A.A. and Harris, S.G. (2002). Crafting a change message to create transformational readiness. Journal of Organizational Change Management, 15(2), 169-183.
Barr, P.S., Stimpert, J.L. and Huff, A.S. (1992). Cognitive change, strategic action, and organizational renewal. Strategic Management Journal, 13(S2), 15-36.
Bashein, B.J. and Markus, M.L. (1994). Preconditions for BPR success and how to prevent failures. Information Systems Management, 11(2), 7-13.
BCG Henderson Institute (2024). Familiar yet fatal: 10 common pathologies of failed change efforts.
Beer, M., Eisenstat, R.A. and Spector, B. (1990). Why change programs don’t produce change. Harvard Business Review, 68(6), 158-166.
Carroll, C., Patterson, M., Wood, S., Booth, A., Rick, J. and Balain, S. (2007). A conceptual framework for implementation fidelity. Implementation Science, 2(1), 40.
Chatzoglou, P., Chatzoudes, D., Apostolopoulou, G. and Dranidis, D. (2016). Factors affecting ERP system implementation. Journal of Enterprise Information Management, 29(3), 362-393.
Errida, A. and Lotfi, B. (2021). The determinants of organizational change management success. International Journal of Engineering Business Management, 13, 1-15.
Heifetz, R.A. and Linsky, M. (2002). Leadership on the Line. Harvard Business School Press.
Hughes, M. (2007). The tools and techniques of change management. Journal of Change Management, 7(1), 37-49.
Kotter, J.P. (1996). Leading Change. Harvard Business School Press.
Prosci (2024). Why do ERP implementations fail?
Vayyavur, R. (2015). ERP implementation challenges and critical organizational success factors. International Journal of Current Engineering and Technology, 5(4).
Weick, K.E. (1988). Enacted sensemaking in crisis situations. Journal of Management Studies, 25(4), 305-317.
Weick, K.E. (1995). Sensemaking in Organizations. Sage.
Whelan-Berry, K.S. and Gordon, J.R. (2000). Effective organizational change: New insights from multi-level analysis. Academy of Management Proceedings, 2000(1), C1-C6.