Insight: Why IT Projects Fail — And How to Bring Your People With You

Most IT projects that fail do not fail because of the technology. They fail because the people using it were never properly brought along for the journey.

This is something we have been thinking about more carefully recently, partly through conversations with our software partner ScalePad around how managed service providers approach project delivery. What those conversations surfaced was not a new idea for us — it is something that has been embedded in the way we have worked since we founded Ratcliff IT in 2009 — but it gave us useful language to articulate it more precisely. And what became clear is that it is far from standard practice across the industry.

The question behind every IT investment

When a Managing Director, COO, or CFO signs off on an IT investment, they are not buying technology. They are buying an outcome. That might be improved security posture, reduced operational risk, better collaboration, more efficient reporting, or — increasingly — the productivity gains that come from AI and automation.

The technology is the vehicle. The outcome is the destination.

This sounds straightforward. But the gap between deploying a solution and actually achieving the outcome it was meant to deliver is where most projects run into difficulty. A CRM that nobody uses. A password manager that gets bypassed. Multi-factor authentication that was rolled out without explanation and created more friction than confidence. An ERP platform implemented to spec, while staff quietly continued working from spreadsheets because the process change never landed.

From a technical standpoint, those projects may have been delivered. From a business standpoint, they failed.

Change management is not the same as change leadership

The industry talks a great deal about change management: project plans, timelines, technical documentation. These things matter. But change management describes the mechanics of delivery. Change leadership describes something different — the active, human work of helping people understand, accept, and ultimately benefit from a change.

There are practical questions that do not appear on a standard project plan but make a significant difference to how a project lands. Will this change affect how someone does their job day to day? Does the change need to be staged in order to reduce disruption? Do people need training, reassurance, or simply a clear explanation of why this is happening? Are there individuals within the business who could act as internal champions, helping to build confidence among their colleagues?

That last question is particularly worth thinking through. For significant changes — around security processes, AI adoption, new systems — there is real value in identifying a smaller group of early adopters before a wider rollout. A handful of trusted users who can work with the new tool, provide honest feedback, and then speak to their colleagues from direct experience. When people hear from someone at their own level saying the change was straightforward, or that it genuinely improved their working day, that carries weight in a way that a message from an IT provider simply cannot replicate. Internal advocacy is not a nice-to-have. It is often the difference between adoption and resistance.

Where the real work starts

A common failure pattern in IT delivery is treating the implementation date as the end of the project. In practice, that is often the point where the most important work begins.

Training before a change is made matters. Support during the rollout matters. The availability of additional assistance in the weeks that follow matters. Clear communication throughout — not just at the start — matters considerably.

People can only be comfortable with change when they know what to expect. They can only know what to expect if expectations have been communicated clearly and in advance. This is not a complex insight, but it is consistently undervalued in the way IT projects are planned and resourced.

There is also a relationship dimension worth acknowledging. Projects are one of the most significant opportunities an IT partner has to demonstrate how it operates under pressure — how it communicates, how it responds to problems, and how well it supports people through disruption. Done well, a project can substantially strengthen a client relationship. Done poorly, it can undermine years of trust that took far longer to build.

Technology as a positive driver, not an obstacle

When change is handled well, technology should feel like a genuine improvement to working life — something that reduces friction, increases confidence, and makes day-to-day tasks easier. When it is not, it feels like exactly the opposite: another system to navigate, another process imposed from outside, another reason to feel that IT is something that happens to people rather than something that works for them.

The role of a good IT partner is to close that gap. To translate business requirements into technology, and then to translate technology back into practical, understandable terms for the people who actually use it every day. That requires technical competence, but it also requires communication, patience, and a genuine understanding of how change affects behaviour.

This has been true since we started, and it will remain true regardless of what the next wave of technology brings. AI is simply the most current example of a technology that requires exactly this kind of considered, people-centred approach to adoption — and the businesses that navigate it well will be the ones that bring their people with them rather than rolling it out and hoping for the best.

A note on codifying what works

Working with ScalePad helped us articulate this more deliberately and build clearer structure around it within our own team and client processes. The approach itself was already there — it is built into the way we have always worked. What changed was the precision with which we could describe it, and the consistency with which we could apply it.

It also points to something relevant for any business evaluating an IT partner. Ask not just whether they can deliver the technical component of a project. Ask how they plan to bring your people with them. Ask what happens before the system is switched on, and what support looks like in the weeks that follow.

The answers will tell you a great deal about how the project is likely to land.