Post-project reviews often explain disappointing digital programmes with one word: adoption. People did not use the portal, follow the new workflow or return to the platform after their first visit. The recommendation is usually some version of “support adoption better next time”. Then the next project begins with a detailed technology plan and a line near launch marked “training”.

Adoption is treated as if it were a reaction that can only be observed after release. In practice, it is something a programme can design for from the beginning.

That does not make the outcome fully controllable. People have competing priorities, clients retain their own preferences, and even well-designed technology can be rejected. A change plan makes those conditions visible early enough to influence them. It connects the product being built to the behaviour that must change for the investment to create value.

A release plan is not an adoption plan

Digital delivery naturally produces tangible evidence of progress. Teams can demonstrate a screen, an integration or a completed sprint. Architecture, security, testing and deployment all have recognised activities and owners.

Change work is easier to defer. “We have mapped the new workflow for the finance team” receives less attention in a steering meeting than a working product demonstration. Communication and training can also look like tasks for the final weeks, once the product is stable enough to show.

That creates a familiar imbalance: the technology plan runs to dozens of pages while the change plan amounts to a launch email, a webinar and a support address.

The source version of this article included a useful admission from our own experience. On one programme, we raised the absence of change planning during a steering update, accepted an assurance that it would be handled, and failed to keep pressing the point. The technology plan continued to grow. The change plan never appeared. We should have treated that gap as a delivery risk rather than somebody else’s administrative task.

Agencies and technology partners have a commercial boundary here. Their contract may cover design and delivery without extending to organisational change. A responsible partner should identify the risk, although the client organisation still needs a named owner with the authority and knowledge to lead adoption. If neither side owns it explicitly, each can reasonably assume the other will deal with it later.

Start with the behaviour that has to change

“If we build something good, people will use it” is an appealing assumption. Better technology helps, although the availability of a better option does not automatically displace an established habit.

For each user group, describe the change in operational terms:

  • What do people do today?
  • What will they do differently after release?
  • What effort, uncertainty or status does the old approach protect them from?
  • What benefit will the new approach create for them?
  • Which surrounding process, policy or incentive must change too?

Consider a client portal. Internal teams may continue emailing documents because email is familiar, fast and accepted by clients. Clients may ignore portal invitations because nobody has explained which documents will appear there or how access helps them. Training people to locate the upload button addresses only a fraction of the change. The programme may also need a revised client-onboarding conversation, a clear rule about where final documents live, support for access problems and managers who reinforce the new workflow.

Good user research should therefore examine current work as well as desired features. Shortcuts and workarounds are valuable evidence. They reveal the practical need that the existing process meets, including needs the formal process may ignore. Replacing the tool while leaving those conditions untouched invites the workaround to return.

The six elements of a usable change plan

A change management plan can be concise. It should still cover six connected elements.

1. Stakeholders and communication

Map the groups affected by the change, including people who influence use without operating the system themselves. For each group, specify what is changing, why it matters to them, when they need to know and who should deliver the message.

Partners, operational staff and clients will rarely need the same explanation. “We are launching a new portal” describes an organisational event. “From next month, your final reports and approval history will be available in one place” begins to explain a change for a client.

Communication should start while choices can still be influenced. Messages sent only at release ask people to accept a decision in which they had no part and offer little time to resolve legitimate concerns.

2. Task-based learning and support

Feature tours teach the interface. Task-based learning prepares people for the work they need to complete.

Organise guidance around recognisable outcomes: submitting an expense, approving a matter, finding a client document or updating a relationship record. Use realistic roles and data. Provide a route for help at the point of need, since few people retain every detail from a session delivered before they first use the product.

Good user experience reduces the learning burden. It does not eliminate the need to explain a new workflow, especially when the change crosses teams or alters responsibility.

3. A staged introduction

A phased rollout can expose friction before it affects the whole organisation. Choose an initial group that represents real use, has enough motivation to participate and includes people willing to report problems. Avoid a pilot composed only of enthusiasts if their circumstances differ from the wider audience.

Define what the phase is meant to learn and what evidence allows expansion. A staged release without learning questions can become a slow launch rather than a useful test.

4. Feedback with visible responses

Give users a simple way to report confusion, errors and workarounds. Combine direct feedback with observation and usage evidence. People may describe a problem as a request for a feature when the underlying cause is unclear wording, missing permissions or a process outside the product.

Publish what the team has heard and what it will do. Some requests will conflict or fall outside scope. Explain those decisions. A feedback channel that appears to absorb comments without response teaches users to stop contributing.

5. Measures of changed behaviour

Logins alone say little about value. Measure the actions that the investment was intended to enable: completed tasks, repeat use, use across relevant teams, turnaround time, error rates, movement away from shadow processes or client completion of a journey.

Set a baseline before launch where possible. Review leading indicators frequently during the first weeks and outcome measures over a longer period. Segment the results. An apparently acceptable average can conceal one team or client group that has barely adopted the change.

Metrics also need interpretation. Low use may indicate poor communication, an access problem, weak relevance, a difficult interface or a flawed underlying proposition. The number tells the team where to investigate; it does not supply the diagnosis by itself.

6. Intervention triggers and authority

Decide in advance what result demands action, who investigates and what options are available. If task completion falls below the agreed threshold, will the team interview affected users, revise training, simplify the workflow or pause the next rollout phase?

Without a trigger, weak adoption can become a disappointing chart that everybody observes and nobody owns. The programme may still be labelled complete because the technology was released, even though its intended value has not appeared.

The adoption owner needs time and authority to act. Naming someone after launch, without budget or access to the product team, assigns responsibility too late and without the means to fulfil it.

Integrate change work into delivery

The change plan should share milestones with the delivery plan.

During discovery, map existing tasks, incentives, stakeholders and workarounds alongside product requirements. During design, test the new workflow and the explanation of it. During the build, prepare task-based support, involve credible champions and establish baseline measures. Before release, confirm ownership, escalation routes, thresholds and the sequence of user groups. After release, monitor behaviour, investigate friction and adapt both the product and its surrounding process.

This integration prevents a false handoff in which the delivery team completes the product and the organisation begins thinking about use. Go-live is the point where adoption evidence starts arriving. It is not the end of the programme’s responsibility for value.

Technology quality and change quality depend on each other

The title of this article is deliberately provocative. Change management cannot rescue a product that is insecure, unreliable or poorly matched to the work. Equally, sound technology cannot create value while the organisation continues to reward and support the old behaviour.

The practical problem is the imbalance. Firms commonly invest heavily in the visible precision of technical delivery and leave the conditions of use implicit. Correcting that imbalance does not require a second bureaucracy. It requires six elements, begun early, tied to delivery decisions and owned by someone able to respond.

If you want a starting structure for your next programme, download the six-element change management plan using the form below. Use it during discovery, then keep it beside the technology plan throughout delivery. The useful outcome is more than a successful launch. It is evidence that people have changed the work in the way the investment was intended to support.