Keeping adoption owned after the project team leaves
A fictional adoption case: the project closed on time; the adoption curve flattened a month later.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01The outcome
Named operating owners for the process, the platform, data, adoption and the business outcome; a friction register feeding one governed backlog; a release cadence; and a monthly adoption review that decides.
The project team disbanded at go-live. Support tickets pile up, workarounds spread, and nobody is accountable for whether the new process is followed or improved.
Who owns adoption, the process and the platform after the project—and how does what users struggle with change the design?
Hand each project responsibility to a named operating owner before go-live, and treat recurring friction as design input with an owner and a release—not as support volume.
A CRM rollout finished on schedule and the project team moved to other work. Three months later, the support desk handles requests one by one, users have built workarounds for slow approvals and missing data, managers are drifting back to exports, and change requests reach the platform team with no owner to prioritize them.
02The reality · current state
How work actually happens today.
- Every project role disappeared at go-live
- Support tickets handled one by one, never analysed
- Workarounds spread with nobody recording them
- The platform team decides priorities by default
- Adoption not reviewed since the go-live report
03Approach
Not the obvious response—the approach.
A support desk answers questions one at a time. Without an owner who changes the design, the same friction returns every week.
- 01Map project responsibilities
List what the project team did that must continue.
Programme lead - 02Name operating owners
Process, platform, data, adoption and business owners—before go-live.
Business owner - 03Open the friction register
Recurring tickets, workarounds and exceptions, classified by type.
Adoption owner - 04Govern the backlog
One backlog, prioritized by the process owner, with a release cadence.
Process owner - 05Review adoption monthly
Signals by level, with decisions and owners.
Adoption owner
04Role value
What each role gives, gets and decides.
| Role | Gives | Gets | Decides | Should not have to |
|---|---|---|---|---|
| Process owner | Priorities, decisions on changes | Friction classified by type and volume | What changes in the process | Read raw support tickets |
| Platform owner | Releases, technical health | A prioritized backlog with owners | How changes are implemented | Decide priorities by default |
| Adoption owner | Signals, enablement, the friction register | A forum that decides | What is reported and escalated | Own fixes that belong to other owners |
05Key dimension · Ownership handoff & friction loop
From project roles to operating owners—and friction into the backlog
Each responsibility the project held gets an operating owner and a cadence. Recurring friction is recorded with its cause, type and action.
- Process decisions
Project design authorityProcess ownerMonthly process review - Configuration and releases
Project build teamPlatform ownerPer release - Enablement and adoption signals
Project change leadAdoption ownerMonthly adoption review - Data definitions and quality
Project data workstreamData owner per conceptMonthly data forum - Local support and feedback
Project super-usersLocal championsWeekly in the first months
| Friction | Cause | Type | Action |
|---|---|---|---|
| Discount approvals wait days | One threshold for every deal | Process | Tier approvals by amount |
| Customer address retyped | ERP data not shown in the CRM | System / integration | Expose the authoritative address |
| Monday pipeline exports | No review view | UX / operating model | Build the review workspace |
The same three frictions had produced most of the support tickets. Fixing them did more than any reminder.
06Adoption signals
How we know it is working—each signal with an owner.
| Signal | Level | Owner | Meaning | Action |
|---|---|---|---|---|
| Friction items closed by a release | L5 · Improvement | Process owner | The design is improving | Review the release impact on the related signal |
| Recurring ticket categories | L5 · Improvement | Adoption owner | Friction the design has not fixed | Move to the friction register with a cause |
| Exports before management reviews | L3 · Management adoption | Business owner | Management drifting out of the system | Find what the view lacks |
07The trade-offs
Credible options, judged against these premises.
Support desk only
Stable processes with few changes
Cost: Friction answered, never fixedKeep the project team indefinitely
Very early after a large go-live
Cost: Ownership stays temporaryNamed operating owners, friction register, governed backlog
Any system meant to keep improving
Cost: Owners with time, a register and a review cadence08The second layer
Questions that change the design.
Ownership
- Who owns changes after go-live?
- Who owns adoption—and what can they decide?
- Who owns each data concept?
Friction
- Where are recurring workarounds recorded?
- Who classifies friction by cause?
- Which fixes go into the next release?
Cadence
- Which forum reviews adoption?
- How often are releases?
- When is the design itself reviewed?
09Decisions & outputs
What the work produces.
- 01Ownership handoff model
- 02Friction register
- 03Governed post-go-live backlog
- 04Release cadence
- 05Monthly adoption review