Why Technology Programmes Fail — And How to Make Them Work
Technology programmes have become the backbone of organisational transformation. Whether introducing a new ERP system, deploying AI-driven insights, or modernising legacy infrastructure, these initiatives carry huge promise. They also carry risk. Study after study shows that many large-scale programmes fail to deliver their intended value, often falling short of expectations in cost, time, or adoption.
The reasons are not always obvious. Yes, flawed planning and execution play a part, but beneath the surface lie deeper issues—many of them human. To understand why programmes fail and how they can succeed, we need to look at the interplay between technology, people, and leadership.
Familiar—and Not-So-Familiar—Causes of Failure
The well-known culprits tend to dominate post-mortems: unclear goals, scope creep, lack of sponsorship, poor vendor management, and unrealistic deadlines. These are real, but they only tell part of the story.
Less discussed, but equally damaging, are the subtler causes:
-
Technology-first thinking: Programmes designed around what the system can do, rather than what people actually need. The result is technically sound solutions that feel irrelevant or cumbersome to end-users.
-
Change fatigue: In environments where one transformation follows another, people grow tired. Even promising initiatives can wither in the face of scepticism and exhaustion.
-
Cultural blind spots: Organisations often underestimate how existing habits, values, and unwritten rules can undermine adoption. What works on paper may fail in practice if it collides with workplace culture.
-
Over-optimism: Leaders and sponsors may set expectations based on best-case scenarios, creating a delivery plan that is fragile from the start.
Failures, in other words, often stem not from broken code or hardware, but from a misalignment between technology and the human systems into which it is introduced.
Human-Centric Change: More Than a Buzzword
“Human-centric change” has become a popular phrase, but its meaning is often misunderstood. At its core, it is about designing technology-enabled change with people, not just for them. It recognises that employees are not passive recipients of new tools but active participants in shaping whether those tools create value.
In practice, this means:
-
Listening early and often: Engaging people at the start to surface their pain points and priorities. This avoids the pitfall of rolling out solutions that don’t solve real problems.
-
Co-creation and iteration: Inviting representative groups to test, adapt, and influence design choices so the solution grows with their input.
-
Practical support: Offering not only technical training but also peer networks, “champions,” and opportunities to build confidence. Adoption becomes less about compliance and more about empowerment.
-
Acknowledging emotion: Change can generate fear, resistance, and uncertainty. A human-centric approach does not dismiss these feelings but works with them, creating safe spaces for dialogue.
Far from slowing things down, this approach accelerates adoption. When people feel seen, heard, and equipped, they are far more likely to embrace new ways of working.
The Leadership Factor
If human-centric change is the engine, leadership is the fuel. Technology programmes live or die by the quality of leadership behind them. Leaders play three critical roles:
-
Sponsor: They champion the change, connecting it to the organisation’s strategy and values.
-
Communicator: They craft and sustain the narrative—why this matters, what it will achieve, and how it connects to people’s day-to-day realities.
-
Role model: They demonstrate through their own behaviour that they believe in the change.
But leadership is also where the pitfalls lie:
-
Invisible sponsorship: If leaders delegate too much and fail to show up visibly, employees perceive the programme as low priority.
-
Conflicting messages: Competing strategic initiatives or shifting priorities can erode trust in the programme.
-
Detachment from reality: When leaders are too far removed from the experience of frontline staff, they may underestimate the friction people face.
The strongest leaders combine clarity and humility: clarity in articulating a consistent vision, humility in listening, adapting, and acknowledging challenges.
And finally, technology itself rarely fails. Code can be rewritten, systems can be integrated, and processes can be redesigned. What truly determines success is the organisation’s ability to bring its people on the journey.
When programmes respect the human side of change and when leaders lean in with both conviction and empathy, technology becomes what it was always meant to be: an enabler of progress, not an obstacle.
Thanks for sharing, Andrew. I view most IT systems as organizational transformation projects, that happened to be enabled by a technology. The real challenge is getting people to change the way they do their job on a daily basis to include using the new technology (as intended and as designed).
When I speak with c-suite leaders (in IT and other departments), I often ask them:
1. Who owns ensuring the systems are adopted and are delivering intended business value? (Typically, no one.)
2. When and how will you measure the value your tech investment has delivered to the organization?
3. What structures and processes have you put in place to ensure you achieve and sustain high levels of effective user adoption and ROI, year over year?
4. When you created your business case for your IT investment, did you assume 100% effective user adoption, or did you adjust your anticipated ROI and timeline based on different levels of user adoption? What happens if you only achieve 40% user adoption? What happens if it takes you an extra 12 – 18 months to achieve assumed adoption levels?
For most of my careers, the view of IT has been, “the business owns the data”, and now it has morphed into, “the business owns adoption and ROI.” Yet, most business leaders lack experience and knowledge regarding how to get their people to effectively adopt systems. There is a need (and opportunity) for IT to guide business leaders in how to ensure systems are effectively used and delivering the required business outcomes.
Thanks for the comments – The questions you’re asking are spot on – I’ve seen many business cases assume near-perfect adoption without a clear plan for achieving it — or for measuring and sustaining it over time. That gap between expectation and reality is where so many programmes falter.
I’m curious: in your experience, what’s the most effective way IT leaders can proactively support business stakeholders in driving adoption and realizing ROI — especially when those stakeholders may not have a background in change management or user engagement?
Hi Andrew,
There are many things that IT leaders can, and in my opinion, must do, to help business stakeholders. Here are just a few:
1. IT needs to convince business leaders that a key organizational competency they must develop is the ability to ensure technology is not merely deployed, but is actually used in way that delivers clear value. The reality is, most organizations can get systems live, but few are actually good at getting full value from their use. This needs to change.
2. As you mentioned, it should be assumed that most stakeholders do NOT have a background in change management or engagement. These are critical skills for the organization. For example, in my experience, the immediate supervisor is the biggest driver of user adoption, and many times they have never been told this is part of their job, and they don’t know how to do it. They will probably need some training and support to ensure they do this. The good news, this is a repeatable skill that they can apply to all future system implementations and process changes.
3. IT, along with finance, need to require that all IT projects must have a comprehensive user adoption and value realization plan (ROI Plan) in place as part of the project approval process. Quite simply, you have no business putting money into a system until you have a plan for how you will ensure you get value out of it.
– This plan must be drafted by the business, and include things such as defining the specific business goals to be achieved, how they will be measured, when they will be measured, and who on the business side is accountable for achieving these goals.
– It also should include the activities, resources (internal and, if necessary, external staff), and budgets. It should cover a period from today and cover for a period of 3 – 5 years after go-live. While you won’t know every detail about what will be required in the future, you must plan that there will be a need to do ongoing user adoption activities, such as onboarding and driving adoption by new employees, as well as activities to drive adoption of new features as they get released.
4. I have trained several internal IT teams on user adoption and ROI methods, and they are usually quite excited to learn techniques to drive user adoption and technology value. While this often is not a core part of their job, they can work to help lead the business in understanding the need for work here, and then partner with them to ensure that they systems they build actually have their intended impact. This can start small working on one system, and once you get some experience, you can expand this effort to build an internal Technology Adoption and ROI Center of Excellence. This CoE can work with the business units to drive more value across the entire technology portfolio.
I worked with one organization that recognized the getting the system live was going to be easy, but managing change and adoption was 80% of their need. They brough us in to build a change and adoption strategy and team 6-months before they selected the final vendor. This focus on adoption allowed us to get ahead of many change management issues, and allowed us to start making organizational changes in preparation for go-live long before the technology was ready. By getting ahead of things, the organization was starting to realize value even before the system was deployed. This is a model that can work for many organizations.
I’d agree with the basic premise of what you say – change programmes fail because of the human factors; almost never because of technology, although clearly getting that piece wrong is unhelpful to say the least!
What I would say is that in my opinion there are no Technology Programmes – only business programmes. That may seem a semantic point, but it really isn’t. Too many programmes I’ve seen fail because they are led by CTOs or technology leaders. The business leaders must own the change and it must be business driven.
I completely agree with you. Calling them “technology programmes” can unintentionally reinforce the wrong ownership. As you say, they’re business change initiatives that use technology, not technology projects in isolation. Success really comes from business and technology leaders working in true partnership, each bringing their expertise to deliver lasting change.
Thank you for the excellent overview! It provided exactly the insights I needed for my Change Program.