Organisational change and adoption¶
Trigger¶
Technology or process change requires people to work differently for the intended outcome to materialise.
Intended outcome¶
Affected cohorts are ready, adopt the new behaviour and produce evidence that supports the intended business benefit.
Workflow steps and gates¶
| Step | Accountable role | Activity | Handover | Gate |
|---|---|---|---|---|
| 1 | Business Relationship Manager | anchors the change in a business outcome, sponsor and affected relationship context | business outcome and stakeholder context | There is a named sponsor and business outcome |
| 2 | Organisational Change and Adoption Manager | assesses stakeholder impacts, readiness and adoption barriers | change impact assessment and adoption strategy | Every material cohort has impact, readiness and owner |
| 3 | IT Trainer | turns role impacts into role-based learning and performance support | training assets and proficiency checks | Training maps to changed tasks and has proficiency evidence |
| 4 | Product Manager | coordinates release timing and product communications with adoption readiness | release/adoption alignment | No cohort is asked to adopt functionality unavailable or unstable in its wave |
| 5 | Product Analyst | measures actual usage and behavioural outcomes | adoption observations and segmentation | Adoption is measured by behaviour/outcome, not attendance alone |
| 6 | Benefits Realisation Manager | connects adoption evidence to benefit realisation and corrective decisions | benefit/adoption review | Below-target adoption or benefits have owned reinforcement or reforecast actions |
Running this workflow: operator and implementer boundary¶
In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.
For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.
How to use this workflow¶
A practical prompt pattern is:
Apply the
organisational-change-and-adoptionworkflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.
Operational interpretation¶
The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.