Digital Transformation
Your IT projects are failing.
It’s not the code’s fault.
Why user adoption remains the real challenge — and what you can concretely do to get ahead of it.
The project is delivered on time. The budget is respected. Every feature is there. Six months later, the teams have gone back to their old Excel files. You may have already lived through this scenario — and it illustrates the true Achilles’ heel of IT projects: failure is not technical, it’s human. In the vast majority of cases, it is user adoption that makes the difference between a successful deployment and a wasted investment.
User adoption in IT projects: numbers that should raise the alarm
For thirty years, the Standish Group has published its famous CHAOS Report, analysing tens of thousands of IT projects worldwide. The finding is damning and remarkably consistent: the IT project success rate has plateaued at around 29%, regardless of methodology.
70%
of digital transformations fail to meet their objectives
(McKinsey)
63%
of CRM projects never reach their full potential
(Merkle Group)
2/3
of employees resist, to varying degrees, organisational change
What is even more striking is the analysis of root causes. According to a McKinsey study, the vast majority of these failures do not stem from technical issues — insufficient budget, poor deployment, flawed architecture — but from human causes: the attitude of employees and the behaviour of managers in the face of change. In other words, it is the user adoption problem that dooms most IT projects.
Key figure
Organisations that invest in cultural change are 5.3 times more likely to succeed in their digital transformation than those that focus solely on technology. (McKinsey)
Why user adoption fails in IT projects
Before looking for solutions, we need to understand the mechanisms behind resistance. It is not irrational: it is often the logical response of an individual to a situation they perceive as a threat or an imposed constraint.
1. The tool does not address their day-to-day reality
A founding principle that is often forgotten: a tool is not adopted because it is technically sophisticated, but because it solves real problems experienced by end users. When business teams have not been involved in the design phase, the result is frequently a tool that looks “perfect on paper” but does not fit real workflows, operational constraints, or working habits.
Typical case
A company deploys a new collaborative management platform. Technically flawless. But the sales team sees it as an extra layer of administration with no tangible benefit for their daily work. Result: they carry on using their usual tools in parallel, and the platform becomes a “feature graveyard”.
2. The question “What’s in it for me?” goes unanswered
This is the central question of any organisational change. Without a clear answer to the WIIFM question, employees perceive the transformation as a threat rather than an opportunity. Resistance is rarely open: it shows up as quiet scepticism, gradual disengagement, or a slow drift back to old habits once the initial enthusiasm fades.
3. Training is confused with change support
Many organisations make do with a launch training session — one or two workshops, a user manual, and good luck. Yet training someone to use a tool and supporting them through a change in practice are two fundamentally different things. The first transfers knowledge. The second transforms behaviour. It takes time, iteration, and sustained follow-up.
4. The change is announced, not co-built
When leadership decides on a reorganisation project, staff often face a choice between accepting the change or leaving the organisation. This stark reality fuels structural resistance. Conversely, projects that involve future users from the design phase generate naturally stronger buy-in, because the people affected become co-authors of the change rather than mere recipients.
The ADKAR model: thinking about change one person at a time
Developed by Jeff Hiatt in 1998 based on a study of over 1,000 organisations, Prosci’s ADKAR model is one of the most widely used frameworks for structuring change management in organisations. Applied to IT projects, it provides a structured way to drive user adoption, ensuring that each individual moves through five stages in order.
A
Awareness
The individual understands why the change is necessary. Without this understanding, no subsequent step makes sense.
D
Desire
The motivation to participate in the change. It cannot be mandated: it is built by answering the WIIFM question and addressing legitimate fears.
K
Knowledge
Knowing how to change: training, procedures, documentation. This is often where organisations invest the most… but it is rarely where the real bottleneck lies.
A
Ability
Being able to apply what has been learned in real working conditions. This is where “classic” training shows its limits.
R
Reinforcement
Sustaining new behaviours over time through recognition, feedback, and correcting deviations. The most commonly neglected step.
“Sudden or poorly managed changes can harm, or even destroy, organisations that are not prepared or equipped to deal with them.”
— EBSCO Research, ADKAR Change Management Model
6 levers to drive user adoption in your IT projects
The good news: user adoption is not inevitable failure. It can be built, planned, and managed — provided you think about it from day one, not at deployment time.
| 01 | Involve end users from the design phase. Interviews, co-design workshops, early user testing: the tool must be built with them, not for them. Applying Design Thinking to IT projects ensures the solution genuinely fits real needs. |
| 02 | Explicitly answer the WIIFM question. For each user profile, clearly articulate what the change concretely brings them — time saved, reduced cognitive load, better visibility. This communication work is not superficial: it is strategic. |
| 03 | Identify and mobilise change champions. Credible internal relays — neither management nor IT — who use the tool, vouch for its value, and support their colleagues day to day. Their credibility is unmatched. |
| 04 | Distinguish training from ongoing support. Plan structured post-deployment follow-up: drop-in sessions, Q&A sessions, usage dashboards, collected and acted-upon feedback. Adoption is not an event — it is a process. |
| 05 | Measure adoption, not just delivery. Define usage metrics from the start: active login rates, features used, user satisfaction. What doesn’t get measured doesn’t get managed. |
| 06 | Budget for change management. Experts recommend allocating between 10 and 20% of an IT project’s total budget to change management. It is an investment, not an expense. |
Digital transformation: culture before technology
McKinsey’s data is unambiguous: company culture, more than technology, remains the primary obstacle to digital transformation. Organisations that invest in cultural change are 5.3 times more likely to succeed than those that rely solely on tools.
This finding echoes a consistent field observation: projects that fail generally do not lack budget or technical expertise. What they lack is a shared vision, honest communication about the stakes, and visible leadership that embodies the change itself.
Key takeaway
According to the Standish Group, the three primary success factors in an IT project are: user involvement, management support, and a clear statement of requirements. All three are human, not technical.
User adoption in IT projects: shifting perspective
If you take one thing away from this article: you don’t deploy a tool, you change habits. User adoption in IT projects is built from day one — by involving users in the design, communicating early on the “why”, investing in support beyond initial training, and measuring usage the same way you measure delivery. For a deeper dive into practical methods, read our guide on change management in organisations.
The organisations that succeed in their digital transformation are not necessarily those with the best technology. They are the ones who manage to bring their teams along for the journey.
Your next project deserves better than a failed rollout.
32steps helps organisations manage change and drive user adoption in their IT projects. Let’s talk about your context.
Sources & references
- Standish Group, CHAOS Report (1994–2020) — analysis of over 50,000 IT projects. standishgroup.com
- McKinsey & Company — research on failure rates in organisational transformations and the impact of culture on digital success.
- Prosci, ADKAR Model (Jeff Hiatt, 1998) — change management methodology based on over 25 years of research. prosci.com
- Gartner & Forrester Research — statistics on CRM project failure rates (47–55%).
- Merkle Group — study on CRM adoption: 63% never reach their full potential.
- Harvard Business Review — 60% of employees feel anxious about major workplace transformations.
- Best of Business Analyst — Why do IT projects fail?
- MeltingSpot — Why digital transformation projects still fail in 2025
You might also be interested in this article:
«Managing Change in Business: Practical Methods and Insights»
For any questions or to discuss a project, feel free to contact us by email — we’ll be happy to get back to you.
Follow our Pinterest page for visual inspiration and fresh ideas around digital transformation and Product Management.
