Change Management for SaaS Rollouts: The Adoption Problem

Here’s a failure mode that doesn’t show up in implementation post-mortems as often as it should.

The project goes live on schedule. The QA testing is clean. The data migrated successfully. The integrations are working. By every technical measure, the implementation succeeded.

Six months later, half the team is still using the old system. The new platform’s active user rate is 40%. Key workflows that were supposed to improve by 30% haven’t moved. The business case hasn’t materialised. The sponsoring executive is asking what went wrong.

What went wrong is the adoption problem. And it’s far more common than most implementation teams acknowledge.

 

What the Adoption Problem Actually Is

The adoption problem is not a training problem. That distinction matters, because most organisations respond to adoption failure by running more training. More training on a system people have decided not to use doesn’t fix the underlying cause.

Adoption failure happens when a new system is technically deployed but doesn’t change how people work. Users find workarounds. They do critical tasks in the old system, in spreadsheets, via email, anywhere except the new platform. The new system becomes a data-entry obligation rather than the actual operating environment.

 

Why People Revert

This happens because behaviour change is hard. People have developed efficient personal workflows over years. A new system asks them to rebuild those workflows from scratch, in a tool they don’t know well, while their normal workload hasn’t decreased. The short-term cost of learning the new system is immediate and concrete. The long-term benefit is abstract and distant.

Without deliberate change management built into the project from the start, the path of least resistance wins. People revert. Adoption stalls. The business case doesn’t materialise.

 

Why Training Two Weeks Before Go-Live Isn’t Change Management

The typical implementation change management programme looks like this: two to three weeks before go-live, training sessions are scheduled. System features are demonstrated. Users are given access to the training environment. A “go-live readiness” survey is distributed. On go-live day, a help desk number is circulated.

This is not change management. It’s a training event bolted onto the end of a technical project.

 

The Retention Problem

Training delivered two weeks before go-live has a well-documented retention problem. Users who are trained on a system they can’t yet use in production forget most of what they were taught by the time they need to use it. The gap between training and practice destroys retention. Studies on adult learning consistently show that skills not practised within 72 hours are largely lost within a week.

 

The Process Redesign Problem

Beyond retention, late-stage training misses the harder problem: process redesign. A new SaaS platform doesn’t just change the tool. It changes the workflow. Processes that worked in the old system often need to be redesigned for the new one. That redesign needs to happen before go-live, with the people who will execute those processes, so they understand not just what button to press but why the new workflow is better than what they had. That conversation can’t happen two weeks before go-live. It needs to happen in sprint two.

 

The Business Champion Model

The most effective change management structure for SaaS implementations centres on business champions: people within each functional area who are given early, deep exposure to the new system and tasked with driving adoption within their team.

 

Who Business Champions Are

Business champions are not super-users identified the week before go-live. They are people who participate in design decisions, UAT, and process redesign throughout the project, who understand not just how the system works but why it was configured the way it was. When their colleagues struggle after go-live, they can answer “how do I do this?” and “why does it work this way?” Those are different questions and both matter.

 

What Business Champions Need

Effective business champions need genuine preparation: involvement in the implementation process from early stages, access to the system in a test environment well before go-live, documented guidance on the new processes in their area, and dedicated time allocated to supporting their team post-launch.

They also need organisational backing. A business champion who recommends the new system gets asked difficult questions by colleagues who prefer the old one. Without visible support from team leaders and senior stakeholders, business champions lose credibility quickly. Change management that isn’t backed by management isn’t change management. It’s wishful thinking.

 

Measuring Adoption, Not Go-Live

One of the most damaging patterns in implementation projects is declaring success at go-live. Go-live is not an outcome. It’s a starting point. The outcome is adoption. The outcome is that people use the system, workflows run through it, and the business case materialises.

 

What to Measure

Adoption should be measured, tracked, and reported, not assumed. Useful adoption metrics include: active users as a percentage of licensed users (weekly); key business workflows completed in the new system versus legacy workarounds; support ticket volume and categories (high ticket volume on the same workflow indicates a process redesign problem, not a training problem); and time-to-complete for key processes (if people are slower in the new system than the old one six weeks after go-live, something is wrong with the process design).

These metrics don’t just tell you whether adoption is happening. They tell you where adoption is failing and why, which makes the remediation specific rather than generic. If one team has 85% adoption and another has 40%, the problem is not training. The problem is something specific to that team’s workflow in the new system. Measure first, then act.

 

Building Change Management Into the PM Workstream

Change management on SaaS implementations should be a defined workstream within project management, not a separate programme that runs alongside the technical project or a phase bolted on at the end.

 

Sprint One

Identify business champions in each affected functional area. Document current-state workflows for the top five processes in each area. Establish the baseline metrics that will be used to measure adoption post-go-live. Brief sponsors on their role in visible change leadership.

 

Mid-Project Sprints

Business champions participate in sprint reviews and provide feedback on delivered functionality from a user perspective, not a technical one. Process redesign workshops run for each area as relevant features are built and confirmed. Early training begins in a sandbox environment, not for the whole user base, but for business champions and power users who will support others at go-live.

 

Pre-Go-Live

Role-specific training on actual business workflows, not system features. Business champions running training sessions in their own areas, supported by the PM team. Go-live readiness assessed against adoption readiness criteria, not just technical readiness.

 

Post-Go-Live

Adoption metrics reported weekly for at least the first eight weeks. Business champions actively supported and visible. Identified workflow problems addressed quickly. Nothing erodes adoption momentum faster than a known problem that isn’t being fixed.

 

The Uncomfortable Truth About Technical Success

Implementation teams are typically structured and incentivised around technical delivery. Go-live is the milestone. The project is declared done when the system is live. What happens after go-live, whether people use it, whether the business case materialises, is someone else’s problem.

 

Where This Leads

This structure produces technically successful implementations that fail commercially. The system works. The ROI doesn’t arrive. The board asks why the $800,000 implementation didn’t deliver the efficiency gains in the business case.

The answer is always some version of the adoption problem. And the adoption problem is always preventable, if change management is built into the project from sprint one, if adoption is measured rather than assumed, and if the implementation team is accountable for the outcome, not just the go-live.

A SaaS implementation that goes live on time, on budget, and with 40% adoption has not succeeded. The measure of a successful implementation is what happens six months later.