A governed workstream, not the closing weeks of build.

The position

Adoption is not a phase

Adoption is not a phase. It is not the last 5% of the programme. It is not "change management" loosely understood as communications and training. It is a parallel workstream with the same governance discipline as build, test, data migration, integration and NFT.

That position has consequences:

• Adoption has a named owner. The Change Lead, from Benefits & Continuous Alignment (S5) onward.
• Adoption has stage-gate criteria. The same checkpoint discipline applies — items not yet evidenced are formally accepted with rationale, never waved through.
• Adoption has measurable outputs at every stage. Stakeholder maps, comms cascades, training-needs analyses, train-the-trainer programmes, role-based training, reinforcement plans. None of these are vibe.
• Adoption is reviewed at the same governance cadence as the rest of the programme. Steering Committee. Design Authority where role design and security architecture intersect. The same evidence standards.

This position exists because BAU IT culture doesn't bring transformation rigour with it by default. Day-to-day operations reward closing the ticket, hitting the deployment date, moving on to the next thing — and that is the right behaviour when the system is stable and the work is incremental. ERP transformation is neither. It needs discipline, structure, accountability and order, sustained over eighteen to twenty-four months, against a system the user population hasn't yet seen. Adoption is the workstream that bridges the gap between programme rigour and the operating culture the programme will hand over to. That is why it has to be governed with the same machinery as build and test, not slotted in around them.

The opposite position — adoption as a soft-skills afterthought handled by the change team in the closing weeks — is the most reliable predictor of a programme that hits go-live and underdelivers on benefits.

The workstream sequenced

Across the lifecycle from Stage 5 to Stage 17

Adoption runs across Benefits & Continuous Alignment (S5) through Hypercare & Stabilisation (S17), with named entry and exit points. The shape is:

The two phases that matter most for adoption — and that are most often shortchanged — are Benefits & Continuous Alignment (S5) (because the Change Lead has to be named before stakeholder analysis is meaningful) and Testing through Hypercare & Stabilisation (S14–S17) (because train-the-trainer cascade plus reinforcement is what actually moves people from "trained on the system" to "operating the system at the speed and quality the business case projected").

Change Lead

From Stage 5, through hypercare

The Change Lead is named at Benefits & Continuous Alignment (S5). Earlier than feels comfortable on most programmes, because at S5 there is no system to change to yet — only a vision and a Programme Charter. Naming early means stakeholder analysis is genuinely structured rather than retrofitted, and the comms strategy drafted in Pre-Programme actually informs Selection rather than being written after the SI is on board.

Through the Selection phase (S6–S9) the Change Lead works alongside the Selection workstream — vendor demos at Software Selection (S8) involve named Process Owners, and the Change Lead ensures the buyer-side engagement is structured rather than ad hoc. By Programme Setup & Mobilisation (S10) the Change Lead is ramping; by Testing (S14) the Change Lead is operating at full intensity alongside the Training Lead.

The Change Lead reports into the Programme Manager, but the workstream is governed by the Steering Committee with the same evidence cadence as build and test.

Training Lead, train-the-trainer

The default — done right or done badly

The Training Lead is named at Programme Setup & Mobilisation (S10) — earlier than some methodologies, because training strategy needs to be drafted alongside the Solution Design rather than written from the Solution Design after it's signed off. The Training Lead owns the training strategy, the training-needs analysis, the materials development, and the train-the-trainer programme.

The methodology defaults to train-the-trainer rather than SI-delivered end-user training. End users learn the system from people they already trust to know how the work is supposed to be done; the trainer cohort that the cascade creates becomes the post-go-live first line of business support, which reinforces hypercare without inflating it. SI-delivered end-user training, by contrast, puts the SI's people in front of users for an event and then withdraws them after go-live, leaving end users with nobody local to ask the second question to.

The cost case usually stacks up too — train-the-trainer is cheaper than having the SI deliver training to every user. But that cost driver is exactly where train-the-trainer most reliably goes wrong. Programmes pick trainers on the basis of who can be spared from the shop floor rather than who has the aptitude to train. The cohort ends up populated by people whose careers couldn't be further from training — no comms background, no instructional-design experience, no real desire to be trainers, and sometimes no credibility with the user population they're now meant to lead. The cascade then fails, but quietly, because everyone has been told the local-capability box is ticked.

The methodology's position is that train-the-trainer is the right default, but trainer selection is the work that decides whether the default succeeds. Three criteria:

• Credibility with the user population. Senior Users, Process Owner deputies, named function champions. People the user group already trusts to know how the work is supposed to be done.
• Capability for the trainer role. They can communicate, structure information, run a session, manage a difficult question. Not all good operators are good trainers — being one doesn't qualify someone for the other.
• Willingness to take on the role. Including the post-go-live first-line-support function, which is real work that continues into BAU. Trainers who don't want the role won't reinforce it after the launch comms have died down.

Selecting trainers on availability rather than these three criteria — usually under cost pressure — produces a cohort that presents as local capability when actually it is local appearance. Train-the-trainer done with the wrong people is worse than SI-delivered training, because it hides the gap rather than exposing it.

Reinforcement & hypercare exit

Two pillars: adoption maturity and support readiness

Adoption doesn't stop at go-live. The Hypercare & Stabilisation (S17) period is when reinforcement does most of its work — when the team is using the system in earnest, hitting the edge cases, finding the gaps, escalating defects, and building the muscle memory that turns trained users into competent operators.

Reinforcement during hypercare is structured, not ambient: scheduled refresher sessions for high-risk processes, comms cadence that closes the loop on raised defects, escalation paths that are visible to users (not just to the project team), and explicit handover from the trainer cohort to BAU support roles.

Hypercare exit is by criteria, not by date. Two pillars matter and both have to be evidenced:

• Adoption maturity. System usage volumes against expected, defect rates per business process, a narrow range of user satisfaction signals. The specific measures are set by the Benefits & Continuous Alignment (S5) measurement framework, against the baselines established at Value Definition & Case for Change (S2).
• Support readiness. The support department has had the relevant exposure to the system during build, test, cutover and hypercare. The relevant training has been delivered. The support team is genuinely satisfied — not just contractually responsible — that it can look after the system in BAU. Support handover is signed off formally as a hypercare exit deliverable, alongside the adoption-maturity evidence.

Both pillars fail together. If support readiness is shaky, cautious executives quite reasonably hesitate to call hypercare exit — because the alternative is a BAU support function that hasn't quite landed taking responsibility for a programme the executive has sponsored personally. That hesitation produces hypercare drift: weeks become months, the project team stays on, costs accumulate, and the programme never quite finishes.

The way to avoid that drift isn't to push for early exit. It's to establish the criteria up front, before hypercare begins, and to make sure executives understand the deal at the start of the phase: once both pillars are evidenced — adoption maturity met, support handover signed off — the programme moves on. That's a binding criterion-driven decision, not an open-ended judgement call litigated in the moment. Setting it up front means everyone is working towards the same exit, the criteria can be evidenced rather than debated, and the project team has a clear endpoint to drive towards.

Recurring bad habits

To correct on sight

Seven things that go wrong with adoption across ERP programmes, again and again. Each one feels reasonable when the decision is made; each one costs more than was saved. Correct on sight when you see them in your own programme.

• Naming the Change Lead too late. Benefits & Continuous Alignment (S5) is the latest point at which naming the Change Lead is structurally useful. Naming at Programme Setup & Mobilisation (S10) — when the SI joins — means the stakeholder analysis is retrofitted, the comms strategy is reactive, and the change workstream is playing catch-up for the rest of the programme.
• Treating adoption as communications. Newsletters, townhalls, leadership videos. They are part of the work, but they are not the work. The work is structured stakeholder analysis, role-based training design, train-the-trainer cascades, and measurable readiness assessments. Communications without that underneath is theatre.
• SI-delivered end-user training without a local trainer cohort. Concentrates training in a one-off event and leaves no continuing capability behind. Train-the-trainer creates the trainer cohort that becomes the first line of business support during and after hypercare.
• Picking train-the-trainer trainers on availability rather than aptitude. Train-the-trainer is the right default, but only with the right people. Programmes that pick trainers from whoever can be spared on the shop floor end up with a cohort that has no training background, no comms aptitude, and no real desire to be trainers — and the cascade fails. The criteria are credibility with the user population, capability for the trainer role, and willingness to take it on, including the post-go-live first-line-support function. Train-the-trainer with the wrong people is worse than SI-delivered training, because it hides the gap rather than exposing it.
• Building training materials only after Solution Design is signed off. Means materials production runs parallel to (or after) build, training is rushed in the closing weeks, and the train-the-trainer cascade compresses. Materials development should begin at Solution Design & Full Business Case (S12) alongside design, not at Testing (S14) after build.
• Skipping role-based training in favour of system-feature training. Tells users what the system can do without showing them how their job has changed. Users leave training competent on screens but unsure how to do their actual job tomorrow. The training has to be designed against the role and the day-in-the-life, not the configuration.
• Hypercare exit by date instead of criteria — in either direction. Some programmes exit on a calendar trigger ("eight weeks") regardless of whether adoption and support are actually ready, and inherit a BAU function that can't cope. Other programmes drift indefinitely because the criteria weren't agreed up front, executives reasonably hesitate to call exit, and weeks become months. The fix is the same in both directions: agree the criteria up front (adoption maturity AND support handover signed off), make them binding, and exit when they're met — not before, not after.