Every post-mortem I've ever read for a failed digital project lands on the same word: adoption. Low adoption. Poor adoption. Insufficient adoption. It's there in the summary, underlined, usually followed by a set of recommendations that amount to "next time, we should make sure people actually use it."
And then everyone nods, files the document, and goes off to build the next project in exactly the same way.
I find this genuinely maddening. Because adoption isn't a mysterious force that descends on some projects and not others. It's a design problem. And it's one that almost nobody designs for.
We'll run some training sessions when we go live. That's our change management.
I hear this constantly. Here's the pattern it produces. A firm invests six or nine months building a new portal, a new website, a new internal tool. The technology plan is meticulous - sprint schedules, architecture diagrams, testing protocols, deployment checklists. The change management plan is... well, there isn't one. There's a line in the project plan that says "training" and a vague intention to send an email when the thing goes live.
Three months after launch, someone pulls up the analytics and discovers that 14% of users have logged in more than once. The portal works perfectly. Nobody's using it.
And look, I understand why it feels like enough. You've got a competent technology partner, you've invested in decent UX, the thing genuinely is better than what it's replacing. Surely people will just... use it?
They won't. McKinsey's work on digital transformations found that 70% of transformation programmes fail to reach their goals, with the primary cause being people-related issues - not technology failures. Prosci's benchmarking data shows that projects with excellent change management are six times more likely to meet objectives than those with poor change management. Six times. That's not a marginal improvement. That's the difference between a successful project and a write-off.
There's an assumption buried in almost every digital programme I've seen, and it rarely gets stated out loud because stating it out loud would reveal how flimsy it is: if we build something good, people will use it.
It sounds so reasonable. Of course they'll use it - it's better than what they had. The new portal is faster. The new website is cleaner. The new tool saves time. Why wouldn't people adopt it?
Because people don't change behaviour just because a better option exists. They change when the cost of changing feels lower than the cost of staying the same, when they understand specifically what's different for them, and when the environment around them supports the new way of working. None of those conditions happen by accident. All of them require deliberate design.
I was involved in a project a couple of years ago - a mid-sized professional services firm, maybe 250 people, had invested about £300k in a new client portal. Beautiful thing. Genuinely well-designed. The technology did exactly what it was supposed to do. Six months after launch, fewer than 20% of clients were using it regularly, and the internal team had quietly gone back to emailing PDF reports because it was "just easier." The COO was furious. He kept saying the technology had failed. But the technology hadn't failed. It worked flawlessly. What failed was everything around it.
Nobody had explained to clients why the portal existed or what was in it for them. Nobody had mapped out the specific workflow changes for the internal team. Nobody had identified the three or four people in each department who would have championed the new approach if someone had given them early access and asked for their input. The training consisted of a single forty-five-minute webinar, two days before launch, attended by about a third of the people who needed it.
I'll be honest - I should have pushed harder on this during the build phase. We flagged the change management gap in a steering committee update, got a "yes, we'll sort that" from the programme lead, and didn't follow up with enough force. That's on me as much as anyone. The technology plan ran to forty-seven pages. The change management plan didn't exist. And I let that slide.
This doesn't need to be a monster document. It needs to cover six things, and each of them is straightforward if you think about it at the right time - which is before you start building, not the week before go-live.
Stakeholder communication. Not the go-live announcement. The ongoing communication that starts during the build phase and creates awareness, anticipation, and context. Who needs to know what, when, and in what format? Partners need a different message than junior staff. Clients need a different message than internal users. "We're building a new portal" is not a communication plan. "Here's what's changing for you, here's why, here's when, and here's who to talk to if you have questions" - that's a communication plan.
Training designed around tasks, not features. Most training sessions walk users through the technology: here's the dashboard, here's where you click, here's the settings menu. Task-based training is different: here's how you find your documents in under 30 seconds, here's how you submit an expense in three clicks, here's how you update a client record without leaving the page you're on. One approach teaches the tool. The other teaches the new way of working. Guess which one actually sticks.
I'll admit I underestimated this one for years. I used to think good UX made task-based training unnecessary - if the interface is intuitive enough, people will figure it out. They won't. Or rather, some will, and the rest will revert to whatever they were doing before.
Phased rollout. Start with the users most likely to adopt early. Learn from their experience. Fix the rough edges. Then expand. Deploying to the entire user base simultaneously is the project management equivalent of opening a restaurant and inviting every food critic in London on the first night. You need a few weeks of quiet service first.
Feedback collection. A structured mechanism for users to report problems, frustrations, and suggestions during the first 90 days. Crucially, this needs to be treated as a learning resource, not a complaints channel. If you set up a feedback form and then get defensive when people use it, you've wasted everyone's time.
Adoption monitoring. Measurable indicators of whether users are actually changing their behaviour. Not just logins - actual usage patterns. Are people completing the tasks the tool was designed for? Are they doing it repeatedly? Reviewed at defined intervals during the first six months. Weekly for the first month, fortnightly after that.
Intervention triggers. This is the one nobody ever defines, and it's arguably the most important. What's the specific adoption threshold below which you take targeted action? Decide this before launch. Write it down. Because if you leave it undefined, what happens is that the monthly report shows 14% adoption, everyone agrees it's disappointing, and then nobody does anything because there's no agreed protocol for what "disappointing" triggers. Three months later the report shows 16% adoption and the project quietly gets classified as "completed" in the portfolio tracker while delivering none of its intended value.
The reason change management gets neglected isn't that operations leaders or technology teams are lazy or stupid. It's structural, and it's fixable once you see it.
Technology is tangible. In every sprint review, there's a working feature to demonstrate. A new screen, a new integration, a new workflow. It's concrete. It's visible. Change management progress looks like "we've confirmed the onboarding communication sequence" or "we've mapped the workflow changes for the finance team." Try putting that in a steering committee update next to a live demo of the new portal and see which one gets the energy in the room.
Change management also feels like soft work. In a programme where everything else is measured in technical milestones, the person saying "we need to spend time on adoption planning" can feel like they're slowing things down. I've seen programme managers actively resist adding change management to the plan because it "adds complexity" to the timeline. Which is a bit like saying you don't want to add seatbelts to the car because it adds complexity to the manufacturing process.
And then there's the vendor dynamic. The agencies and technology partners running the delivery are - quite reasonably - focused on the technology deliverables. That's what they were hired for. That's what the contract covers. Very few of them will proactively say "your change management plan is inadequate" because it's not really their problem, and raising it feels like scope creep. So the technology plan gets more and more detailed while the change management plan stays at "training TBC."
None of this is anyone's fault, exactly. But recognising the pattern is the first step to breaking it.
The fix isn't a parallel workstream. It's integration into the phases you're already running.
In discovery, your user research should map current workflows, not just desired features. When you understand how people actually work today - the specific steps, the shortcuts they've invented, the workarounds they've normalised - you produce the raw material for the "here's what changes for you" communication that the change management plan needs. If your discovery phase only produces a requirements document and doesn't produce a workflow change map, you've missed the bit that determines whether anyone actually uses what you build.
During the build, run a communication timeline alongside the delivery timeline. Identify internal champions - the people in each team who are curious, influential, and likely to try new things - and give them early access. Not as a favour, but as a deliberate strategy. When those people start saying "actually, I've seen the new portal and it's pretty good," that's worth more than any training session.
At go-live, don't just launch. Launch into a structured first-90-days adoption programme. Clear metrics. Feedback mechanisms. Intervention triggers already defined. Someone named as responsible for monitoring adoption - not as a side project, but as their actual job for those 90 days.
Then use the evidence from the first 90 days to refine the training, the communication, and the onboarding approach before expanding to the wider user base.
I'll be blunt about what happens when you don't do this, because I've watched it happen too many times.
The portal nobody uses. The licence costs continue. The annual renewal comes around and someone has to justify spending £80k on a platform with 14% active usage. They can't justify it, but they can't kill it either because that would mean admitting the project failed. So it limps along, costing money and delivering nothing, for years. I've seen this exact scenario play out at a financial services firm we worked with - three years after go-live, the platform was still live, still being paid for, and the team had built an entire shadow process in SharePoint to avoid using it.
The website that partners won't promote. Marketing invested six months rebuilding the site. It looks great. It converts well - when people actually visit it. But the partners don't mention it in client conversations, don't share the thought leadership, don't use it as a business development tool. That's not a website problem. That's a change management problem. And it's almost always because nobody sat down with the partners before launch and said: here's specifically how this helps you win work.
And then there's the one that really hurts: the second failed project in three years that makes the third investment nearly impossible to approve. I sat in a board meeting once where a COO was trying to get sign-off for a CRM integration. The CFO's exact words were: "We spent £200k on the client portal and nobody uses it. Why would this be different?" The COO didn't have a good answer because, honestly, the plan was basically the same - build it well and hope people use it. The board said no. The firm lost another eighteen months.
I'm not arguing that change management matters more than technology quality. You need both. A brilliant change management plan wrapped around terrible technology will still fail. But the imbalance I see in practice is almost always in one direction - detailed technology plans with no change management to speak of. And the result is projects that go live on schedule and fail to deliver their intended value on schedule too.
The fix is neither expensive nor complicated. It's six elements, integrated into phases you're already running, owned by someone with the authority to act on what they find. If you want the six-element change management plan as a template you can integrate into your next digital programme from day one, [download it here].
Because the next time a post-mortem lands on the word "adoption," I'd love it to also include the sentence: "and here's what we did about it."