Delivered is not adopted: making a change stick after go-live

The new job management system went live in March. Everyone attended training, the supplier signed off, and the project was closed. By June, supervisors were keeping their own spreadsheets because the system’s reports were “not quite right”, quotes were still being prepared in the old template, and the owner was phoning staff for job updates instead of checking the screen. Every project measure said the change was complete. Very little about how the business worked had changed.

This is common, and it is not mainly a technology problem. Every significant change creates two systems at once. One is formal: the software, the procedure, the new role, the revised structure. The other is behavioural: the habits, incentives and signals that decide what people actually do on a busy Tuesday. The formal system is visible and easy to count. The behavioural system is less visible and usually decides whether the change creates any value.

This article explains why delivered and adopted are different milestones, how to define the behaviours a change depends on, how to measure adoption rather than participation, why a working pilot is not the same as everyday use, and how to catch the drift back to old ways. It is general information for owners and managers introducing new systems, processes or ways of working.

Four common misreadings

Behaviour is a communication problem. People need to understand why a change is happening, but understanding is not doing. If the new process conflicts with how people are paid, how they are measured, their workload or their customers’ demands, more explanation will not fix it.
Adoption belongs to the supplier or a change person. Specialists can train, support and advise. They cannot replace managers. Staff learn what a change really means by watching what managers do when the new way conflicts with the old one.
Participation proves adoption. Training completion, attendance and email reach show exposure. They do not show that work is done differently.
Behaviour settles after go-live. It often drifts back. When support is withdrawn, pressure rises and attention moves to the next priority, familiar habits return.

Declared design and everyday practice

A useful way to see the gap is to compare what the change says should happen with what actually happens under pressure:

Declared: all jobs are scheduled in the system. In practice: urgent jobs are arranged by phone and entered later, or never.
Declared: the team leader decides within agreed limits. In practice: the owner overrides decisions whenever a customer calls.
Declared: the system is the single source of truth. In practice: staff keep private spreadsheets because the official source is inconvenient.

The second column is the one customers and staff experience. Governing a change means managing the distance between the two.

Make the behaviours specific

General aims such as “embrace the new system” or “be more accountable” sound positive but do not tell anyone what to do differently. Identify the few behaviours without which the change cannot work, and describe each so it can be observed:

“Every job is closed in the app before the technician leaves the site.”
“Quotes over $5,000 are prepared in the quoting system, not in the old template.”
“Decisions within the team leader’s limits are not escalated to the owner.”

For each behaviour, ask:

Who must model it first? Usually the owner and managers. If they keep using the old way, everyone else will too.
What currently pushes people the other way? An incentive, a measure, a workload pressure or a customer habit.
What would prove management is serious? Often a visible decision, such as the owner refusing to accept a paper report.
How will we see it happening in real work?
What signal will tell us it is slipping?

A five-layer check

Layer	Question
Outcome	What result must become reliably true?
Behaviour	What will people do differently to create it?
Support	Which process, tool, incentive or authority must change to make that behaviour easy?
Evidence	What observable measure shows it is happening?
Reinforcement	What happens when the old behaviour reappears under pressure?

The third layer is where many changes fail. If people are asked to raise problems early but are criticised when their reports show problems, the message and the system conflict, and the system wins. If a new process adds work for one group while the benefit goes to another, resistance is a rational response, not a character flaw. The helping people accept change article covers understanding what people gain and lose from changing.

Measure adoption, not participation

Better measures of adoption look at the work itself:

Workarounds: the number of parallel spreadsheets, paper forms or manual re-entries still in use.
Use in decisions: whether managers make decisions from the new system’s information.
Path followed: the share of work that goes through the new process without bypassing it.
Old practice disappearing: whether the old template, report or habit has actually stopped.
The outcome itself: the result the change was meant to produce, such as faster invoicing or fewer errors.

Track a few of these for at least six months after go-live, not just until the project closes.

A working pilot is not everyday use

Many changes start with a successful pilot. The pilot proves the idea can work under favourable conditions, often with enthusiastic people and extra support. Moving to everyday use needs more:

Funding beyond the pilot, for full rollout, extra licences, equipment or working capital.
Skills and support for everyone who will use it, not just the pilot group.
Supplier capability to support it at full scale.
Rules and approvals that fit the new way of working.
Incentives that line up: who bears the cost and effort, and who receives the benefit? Where those are different people, expect resistance unless something changes.
The ability to absorb it: someone inside the business who understands the change well enough to adapt and maintain it.

A business can fund many successful pilots and still change little if none crosses the gap to everyday use. The technology is a means, not a strategy article covers checking whether an option can be adopted before choosing it, and proving a new technology is ready to depend on covers testing it under real conditions.

Customers and suppliers have to adopt too

Many changes depend on people outside the business: customers booking through a new portal, suppliers sending electronic invoices, contractors using a shared schedule. They have even less reason to change than staff, because the benefit is mostly yours. Make the new way the easiest one for them, explain what is in it for them, such as faster confirmation, quicker payment or fewer phone calls, and decide in advance how long the old way will remain available. Track their adoption with the same care as your own team’s.

Hand ownership from the project to the business

A change that survives only while the project team or supplier is around is not yet part of the business. Before the project closes, name the person in the business who owns the outcome, not just the system: the office manager who owns invoicing speed, or the operations lead who owns schedule accuracy. Give them the adoption measures, the authority to remove workarounds and a regular place to report progress, such as the monthly management meeting. Project closure should be the moment ownership moves, not the moment attention stops.

Watch for drift back

Old habits return quietly. Plan check-ins at one, three and six months after go-live, and look at the adoption measures, not just whether people say things are fine. Watch especially when:

Support is withdrawn, such as the supplier’s on-site help ending.
The business gets busy, and shortcuts look attractive.
New staff join and learn from colleagues, who may teach them the old way.
A key champion leaves or moves to other work.

When drift appears, treat it as information about the support layer: what makes the old way easier? Fix that before reminding people of the rules.

A worked example

This is an illustration. An 18-person plumbing business introduces a mobile job app so technicians can record notes, photos and parts on site and generate invoices immediately. Training is completed, and the supplier’s project closes.

Two months later, the owner checks how the app is actually being used. About 60% of jobs are closed in the app on site. For the rest, technicians hand in paper job sheets, and the office manager types the invoices, because that keeps things moving. The owner still phones technicians for job updates rather than checking the app. On average, invoices go out nine days after a job is finished.

The owner looks at what pushes people the other way. Technicians are paid per job completed. Entering details in the app adds a few minutes per job and brings them no benefit; the benefit, faster invoicing, goes to the office. The office manager accepts paper because rejecting it creates conflict and delay.

The owner makes five changes:

Models it first. The owner stops phoning for job status and uses the app for updates and decisions.
Specific behaviours. Every job is closed in the app before the technician leaves the site, with parts recorded against it.
Benefits for technicians. Recording parts in the app now automatically triggers restocking of their van, and the end-of-day paperwork disappears. Time spent closing jobs in the app is treated as part of the job.
A clear date. From the first of the next month, the office stops typing invoices from paper sheets, with extra support offered to anyone who needs it.
Adoption measures. The owner tracks the share of jobs closed on site, the number of paper sheets received and the days from job completion to invoice.

Within two months, almost all jobs are closed on site, and invoices go out an average of two days after completion. With monthly invoicing of about $150,000, invoicing seven days sooner brings forward roughly $35,000 of cash, a one-off improvement in working capital.

At the four-month check, paper sheets reappear from one van. A new technician has learned the old way from a colleague. The owner adds an app walkthrough to the induction checklist and pairs new starters with a technician who uses the app well.

How this applies to a small Australian business

Treat go-live as a milestone, not the finish line.
Name the few behaviours the change depends on, in observable terms.
Have managers model them first.
Find what pushes people the other way, and fix it.
Measure workarounds and outcomes, not training attendance.
Plan for the gap between a pilot and everyday use.
Check adoption at one, three and six months.
Include new behaviours in induction for new staff.

Signals worth watching

Parallel spreadsheets and paper forms after go-live.
Managers still using the old way.
Training completion reported as success.
Benefits going to one group while another carries the effort.
Pilots that never become standard practice.
Old habits returning after support ends.
Customers still using the old channel months after the new one opened.

Common mistakes

Closing the project at go-live.
Relying on communication to change behaviour.
Leaving adoption to the supplier.
Measuring participation instead of use.
Ignoring incentives that pull the other way.
Assuming new staff will pick up the new way by themselves.

Frequently asked questions

How long should we monitor adoption? At least six months for significant changes, and longer if the change affects how people are paid or measured.

Should we ban the old way? Often, yes, after a clear date and with support. Leaving both options open indefinitely usually means the old way wins.

What if people have a good reason for the workaround? Then the workaround is telling you something about the new system or process. Fix the cause, then remove the workaround.

Who should own adoption? The manager whose area benefits from the change, with support from whoever led the project.

Can the system itself force adoption? Partly. Required fields, removing access to old templates and automatic workflows help. But people who see no benefit find new workarounds, so pair system controls with fixing the reasons behind resistance.

What if the owner is the one not adopting? Then the change will not stick. Owners set the real standard by what they do, not what they say.

Questions to ask

Which behaviours does this change depend on?
Who must model them first?
What currently makes the old way easier?
Who carries the effort, and who gets the benefit?
What would show us the change has been adopted?
When will we check, and what would tell us it is slipping?

Bringing it together

A change is complete when the business consistently works in the new way, not when the system goes live. Name the few behaviours the change depends on, make them observable and have managers model them first. Fix the incentives and pressures that make the old way easier, measure workarounds and outcomes rather than attendance, and plan for the gap between a pilot and everyday use. Then keep checking after go-live, because old habits return quietly when attention moves elsewhere.

Source: KEVOS notes, drawing on practitioner material on transformation roadmaps and leadership behaviours, the UK Government’s project delivery functional standard on change management, and N. Wakeford and colleagues (2017) on barriers to innovation adoption. Examples and figures in this article are illustrations. This article is general information.