1. A change is a cycle, not an event
Most organizations plan a change as an event: a launch date, a training week, a go-live weekend. The event is real, but it's a small part of what decides whether the change works. What decides it is mostly invisible on the project plan: whether anyone checked that the problem was the one being solved, whether success was written down before the money was spent, whether managers were ready to coach, whether people practised before they had to perform, and whether anyone was still paying attention six months later. #52 · #63
The Database organizes its advice into ten stages because that's where the evidence clusters. Each stage answers one question, and each produces something the next stage needs. Skip one and the work doesn't disappear; it turns up later, at a worse moment and a higher price. #52 · #9
The stages are also a cycle. Adapt, the last one, uses everything learned along the way to change the system, and the next change starts with a better diagnosis than the last. An organization that runs the cycle well doesn't just complete one change; it gets better at change. #64 · KIN-CAP-03
2. Three movements
The ten stages fall into three movements. The first decides what the change is. The second builds the capability to do it. The third makes it normal and keeps it alive.
Measure is set up in Define, when the baseline and success conditions are written down, and runs alongside Support. Adapt feeds the next Diagnose. #10 · #14 · DGN-BSL-01
Decide (Diagnose, Define, Prepare). Most failed fixes were aimed at the wrong problem, and the most common causes of project failure people cite are scope creep, overload and unclear goals, not technology or budget. These three stages exist to stop that: test the problem before naming the fix, write down the future work and the success conditions before buying anything, and get people, partners, systems and knowledge ready before go-live. PM-1 · DGN-CNS-01 · PM-13 · #52
Build (Learn, Apply, Verify). The learning research is unusually clear about what works for adults learning technical work: worked examples, practice from memory, spacing, feedback and whole real tasks. But learning that never meets real work fades quickly, so Apply puts it to use within days, in bounded conditions. Verify then turns claims of competence into evidence; a certificate, a signature or a green status report is a claim, not proof. #2 · LSC-TRF-03 · SOP-TRN-01 · #28
Sustain (Adopt, Support, Measure, Adapt). A change is adopted when the old way has quietly disappeared, and that rarely happens on its own. Support catches everything training couldn't anticipate. Measure separates the change's effect from everything else going on. Adapt turns all of it into decisions, including the decision to stop. This is the movement most often left unfunded, because budgets tend to end at launch. #63 · CM-DIG-03 · #22 · #64
3. What each stage hands the next
The stages connect through handoffs. When a stage is skipped, the next one starts without what it needs, and usually doesn't notice until much later.
| Stage | Hands the next stage | Skip it, and… |
|---|---|---|
| Diagnose | A tested problem, its causes, and what's still unknown | The fix is aimed at the symptom, often "more training" |
| Define | The future workflow, decision rights, information flows and success conditions | Every stakeholder carries a different version of "done" |
| Prepare | Ready managers, partners, systems, knowledge and a rehearsed fallback | Training competes with the backlog the launch created |
| Learn | People who can do the work on an unseen task, without help | Completions are reported as capability |
| Apply | First real use, with deviations recorded as data | Skills fade before they're used; people revert under pressure |
| Verify | Evidence that people, systems and the checks themselves work | The organization relies on a claim |
| Adopt | The new way as the only way, with depth of use measured | Half the teams keep the old spreadsheets |
| Support | Answers at the moment of need, and a record of the questions | Workarounds grow and the workflow drifts |
| Measure | What changed, against a baseline, with the method shown | Nobody can say whether it worked |
| Adapt | Changes made, and a better diagnosis for next time | The same lessons are logged again on the next project |
DGN-CNS-01 · PM-19 · TAR-PLN-02 · LSC-MSR-01 · LSC-TRF-03 · SOP-GOV-05 · GOL-ADP-01 · #21 · DGN-BSL-01 · SOP-GOV-06
4. Where changes usually break
The same failure points turn up across software rollouts, plant changes, new procedures and new sites. None of them is dramatic. Each is a stage done on paper instead of in the work.
- Naming the fix at the first meeting. "We need a course" or "we need a new tool" arrives before anyone has tested what's wrong. Treat "it's a people problem" as a hypothesis that needs evidence. DGN-FRM-04 · DGN-FRM-03
- Defining success after launch. Without success conditions and a baseline written down in Define, Measure has nothing to measure against, and the baseline gets taken at the worst month. #14 · DGN-BSL-01
- Training before the conditions exist. People trained weeks before the system is ready, with no manager ready to coach and no sandbox to practise in, forget most of it. #52 · #11
- Verifying by signature. A read-and-sign form proves someone received a document, not that they can do the work. SOP-TRN-01 · SOP-TRN-06
- Measuring adoption in logins. Logins and completions are cheap to count and almost never answer whether the work got better. CM-DIG-03 · GOL-ADP-01
- Ending support at go-live. The months after launch, when questions are most frequent, often have no owner and no money. #64 · #21
- Logging lessons instead of acting on them. The test of Adapt is not how many lessons were recorded, but how many things changed. SOP-GOV-06 · DQ-LRN-04
5. Size the cycle to the change
Not every change needs every stage at full depth. A new report template and a new payroll system both pass through all ten stages, but the template can move through several of them in an afternoon. The question at each stage is the same; the effort scales with the consequence of getting it wrong and how hard it is to undo. GOL-HYP-08 · QMS-ARC-03
- Low risk and easy to reverse, such as a dashboard or template: a short diagnosis, a smoke test, a rollback plan and a couple of weeks of watching.
- Moderate, such as a common data environment or a field app: a pilot crew, a measured baseline, and four to six weeks of support before scaling.
- High risk, such as ERP, payroll or a manufacturing execution system: a full pilot, a volume contingency, verified competence and reconciliations over two business cycles.
- Safety-critical, such as control systems, new lines or fall protection: hazard analysis, independent sign-off, observed competence, and exit only on criteria.
Two stages are never optional, whatever the size: Diagnose, because a fix aimed at the wrong problem wastes everything after it, and Measure, because without it nobody can tell whether the change worked or should be stopped. PM-1 · #10
6. How to use the briefs
Each stage brief is written to be read in one sitting: what the stage is for, the practices that matter most, figures you can reuse, a "by team" section for technology, projects and construction, plants, safety and finance, and a short list of things to keep current. Read the brief for the stage you're in, then the one after it, because most problems show up at the handoff. #52
If you're starting something new, read Diagnose and Define before anything is bought. If a change has stalled, start with Adopt and Measure, then work backwards: the stage where the evidence runs out is usually where the cycle broke. The topic briefs then follow single ideas, such as onboarding, go-lives and risk, across all ten stages.
The cycle in one line. Find the real problem, say what done looks like, get ready, build skill that lasts, use it on real work, prove it, make it normal, support it, measure it honestly, and change the system based on what you learned.