1. What this stage is for
Adapt uses evidence, questions, failures and outcomes to change the system and restart the cycle. It's where the measurements from Measure, the questions from Support, the deviations from Apply and the gaps from Verify become decisions: change the procedure, fix the template, retire the course, rebuild the pathway, or stop the project. Then the next diagnosis begins, better informed than the last. #64 · KIN-CAP-03
Most organizations are good at writing lessons down and poor at changing anything because of them. A lessons-learned register fills up, the next project repeats the same mistakes, and the reviews start to feel like ceremony. Public inquiries see this at national scale: the Grenfell Inquiry recommended a statutory public record of inquiry recommendations and the government's response, precisely because so many earlier recommendations were never acted on. The test of Adapt is not how many lessons were recorded, but how many things changed. DQ-LRN-04 · SOP-GOV-06 · WF-GOV-02
A useful finish line: every significant lesson has an owner, a change it led to, and evidence that the change worked, and the next cycle starts from a better baseline than this one did.
2. Learn from what happened
Learning starts with an honest account of what happened, which depends on people being willing to give one. Run reviews under a just culture: blame-aware, separating the question of what happened and why from any question of individual culpability, by procedure and by people. Protect psychological safety, so that failure analysis is candid. In environments where admitting a mistake costs a career, reviews produce tidy stories instead of useful ones. SWD-INC-05 · CYBER-27 · DGN-RCA-03 · CS-06
Don't wait for the end. Run after-action reviews during the project, at natural milestones, and reset psychological safety before deadlines, not only at kickoff. A short review after each phase, asking what we expected, what happened, why the difference, and what we'll do next, catches problems while they can still be fixed. After events and incidents, debrief straight away with everyone involved, including other agencies or partners. PM-23 · SEM-33 · HX-18
Three disciplines keep reviews honest:
- Judge the process separately from the outcome. Good process sometimes loses, and luck sometimes rescues bad process. Score how each significant decision was made, against what was known at the time, before discussing how it turned out. A decision log made when decisions were taken is the only fair basis for this. DQ-LRN-03 · DQ-LRN-08
- Look for several causes, not one. Prefer multi-causal learning to a single root cause; for serious events, trace how control failed through management and oversight, not just at the sharp end. SWD-INC-06 · DGN-RCA-01 · QMS-RCA-06
- Investigate near misses like accidents. Weak signals came before many serious failures. Stop-work events, recurring small defects and "lucky" escapes are the cheapest lessons you'll get. DQ-LRN-06 · DGN-RCA-04
When consequences are delayed, reconstruct the causal chain explicitly. People learn poorly from outcomes that arrive months after the decision, because the link is invisible. Laying out the chain, decision by decision, is how a debrief makes that link visible again. GL-07 · GL-02
3. Turn lessons into changes
A lesson counts when something changes. Every lesson should end in one of three things: a change to the system, an explicit decision not to change with the reason recorded, or a test to find out more. "Lessons noted" is not one of the options. SOP-GOV-06 · SEM-34
Separate the correction from the corrective action, define the effectiveness check before closing either, and tier the depth of analysis by risk. QMS-CAP-01 · QMS-CAP-02 · QMS-CAP-04
Prefer structural fixes to procedural ones for chronic problems. A new rule, a reminder or another layer of approval is the easiest response to a recurring failure and usually the weakest. Changing the template, the tool, the default, the incentive or the workflow so the error is hard to make tends to work better and last longer. PM-3 · PM-7
Track every recommendation to closure, in front of the people who can make it happen. Keep one register, with an owner, a deadline and evidence of closure for each item, reviewed at the level that has the authority to act: the board for major reviews, the project leadership for project lessons. Measure what changed on the ground, not only what's marked "implemented". DQ-LRN-04 · WF-GOV-02 · WF-GOV-03
Don't close a corrective action on the evidence that it was carried out. Close it on evidence that it worked, checked after enough time has passed to tell. Have management review ask the same question about the whole set: did the actions we closed last quarter actually fix anything? Then re-test: an intervention to reduce noise or bias in judgments is only shown to work when the next audit shows less scatter. QMS-CAP-03 · QMS-ARC-05 · DQ-LRN-05
4. Change the system safely
Changes made in Adapt are changes like any other, and they carry the same risks. Classify every change by its consequence, and check what it touches before making it. A field change is a design change and needs the same review. A temporary change is still a change. In plants, controller changes go through compile, simulation, review, factory testing and management of change, however urgent they feel. SOP-GOV-07 · SOP-GOV-03 · TAR-SAF-04 · PRM-MFG-02
When the evidence shows a procedure that's followed exactly and still fails, redesign it; don't retrain people to follow it harder. Compare the written procedure with the work as it's actually done before deciding which one is wrong, and favour fewer, better procedures over more. SOP-GOV-11 · DGN-GAP-01 · SOP-DES-07
Re-test controls whenever the systems around them change. A financial control that worked in the old system may not exist in the new one; a safety interlock that worked before a controller upgrade needs proving again. If a control now relies on AI, the AI needs evidence too. FIN-TEC-04 · FIN-TEC-01 · TAR-SAF-03
Keep baselines under control. When a project's plan changes, re-baseline formally, with the change recorded and approved, rather than quietly moving dates. A schedule that's updated by moving dates hides exactly the information Adapt needs. When scope is cut, re-run the benefits and readiness diagnosis, because the removed piece may be the one the benefits depended on. PCF-CHG-01 · PCF-SCH-05 · DGN-RDY-04
Keep learning content in step with the system. When a procedure, standard or tool changes, the training, job aids and refreshers built on the old version are now wrong. Synchronize content with releases, and train people before a changed procedure takes effect. #21 · SOP-TRN-07
5. Continue, change or stop
Sometimes the evidence says the change itself isn't working. This is the hardest call in Adapt, because escalation of commitment is strong and predictable: sunk costs, personal responsibility for the original decision and closeness to completion all push people to keep going. Generic warnings about escalation don't help. Specific decision rules, agreed in advance, do. OGV-ESC-01 · PM-4 · PM-5
- Has a stop rule been triggered?Yes: bring it back to the deciders now, as agreed at approval.
- Is the evidence about the process or the outcome?A bad outcome from a sound process may be bad luck; check before changing course.
- What would it cost to stop, versus to finish?Compare honestly, with the re-baselined estimate checked independently.
- Can a smaller, reversible change fix it?Prefer it, with a checkpoint to see whether it worked.
- Decide, record, and tell people whyIncluding the option you didn't choose, and what would make you revisit it.
Make early bad news cheap and stopping honourable, or people will keep both hidden. OGV-ESC-02 · DQ-LRN-07 · DQ-RT-14 · PCF-RPT-02 · OGV-ESC-03
When a large project resets, have the new estimate checked independently and set it beside the cost of cancelling and the realistic alternatives. Stopping is not cheaper by default, and continuing is not safer by default; the comparison is the decision. DQ-LRN-07 · OGV-PORT-01
Make stopping honourable. A culture in which cancelling a failing project ends careers guarantees that failing projects continue. Recognize the person who raised the flag, and treat a well-reasoned stop as a success of governance. Expect that most projects end "challenged but survived" rather than cleanly succeeding or failing; Adapt is how you make the most of that common middle. OGV-ESC-03 · PM-15
Expect the unexpected inside the plan, too. In plant turnarounds, inspection routinely finds work nobody planned; the turnarounds that cope best plan for discovered work with an assessment process and a contingency, instead of treating every discovery as a crisis. TAR-EXE-02 · PCF-CHG-02
6. Learn across projects
The most valuable adaptations travel. A fix that stays on one project helps one project; a fix that reaches the organization's standards, templates and training helps every project after it. Run a project-to-enterprise learning loop: a deliberate route by which lessons from projects are reviewed, generalized and built into the enterprise's procedures and pathways. KIN-CAP-03 · KIN-CAP-01 · SOP-SYS-05
Treat organizational memory as the result of learning, not an archive. A database of past lessons that nobody reads is not memory. Memory is the set of things the organization now does differently because of what it learned, and the people who know why. Check knowledge readiness at the start of each new project: what did the last similar project learn, and has anyone read it? KIN-CAP-01 · KIN-CAP-04
Use the signals Support collects. Repeated questions, failed searches and routine workarounds show where the system needs to change, often before any metric moves. Treat friction as a sensor, and use knowledge-search behaviour to diagnose gaps. KIN-SIG-01 · #32 · #15
Review the strategy as conditions change. Technology, regulation and the market move; an IT or learning strategy written three years ago may be answering yesterday's questions. Feed results into the next portfolio cycle, so that what you learned changes what you fund. ITG-STR-04 · ITG-VAL-02
Keep the people side adaptive too. Run adoption as a learning loop rather than a fixed plan, keep upskilling existing staff as the work changes, and keep AI-generated learning recommendations explainable and contestable, so people can challenge them when they're wrong. #64 · #5 · #50
7. By team: what adapting looks like
Every team runs some version of the learning loop. The difference between teams that improve and teams that repeat themselves is whether the loop ends in a change. #64 · SOP-GOV-06
Technology and software teams
Software teams have the most mature habits here: blame-aware post-incident reviews, multi-causal analysis and deliberate follow-through. Close the loop by tracking review actions like any other work, and pay down technical debt where the interest is, in the code that changes most often, rather than wherever it's most visible. SWD-INC-05 · SWD-INC-06 · SWD-INC-07 · SWD-TD-02
Project and construction teams
On projects, feed the reasons for missed commitments into the risk register, run after-action reviews at milestones, and re-baseline formally when the plan genuinely changes. Carry lessons into the next project's mobilization, not just into a register: if the last three projects lost weeks to late subconsultant appointments, change the procurement template. CM-LEAN-03 · PM-23 · PCF-CHG-01 · KIN-CAP-04
Plants and operations
In plants, adapting runs through management of change, corrective actions with effectiveness checks, and the condition-based renewal plan. Treat recurring near-identical events as a precursor pattern rather than a series of one-offs, and harden the parts of the operation that the last incident exposed. SOP-GOV-07 · QMS-CAP-02 · FAM-MNT-04 · DGN-RCA-04 · DM-SEC-06
Safety and emergency teams
After an emergency or exercise, debrief with every agency straight away, turn lessons into changes and test them, and plan recovery and mental-health support as part of the response rather than after it. Track the recommendations of reviews with owners and deadlines, publish reviews promptly, and measure what changed on the ground. SEM-33 · SEM-34 · WF-REC-05 · WF-GOV-02 · WF-GOV-04 · WF-GOV-03
Learning and people teams
For learning programmes, each cohort's results should change the next cohort's programme: what to drop, what to move earlier, what new people kept getting wrong. Study the people for whom the programme worked best and worst, and use what you find; keep upskilling existing staff as the work changes; and keep AI-based learning recommendations explainable, so people can challenge them. #64 · IDE-EV-09 · #5 · #50
An illustrative example
After a crisis in which nobody was hurt, a contractor's board was ready to record that everything had gone right. A process review, done against what was known at the time, found two calls that had been sound and two that had been lucky: a crack log from months earlier marked "cosmetic, no action", and a stop-work card closed by a phone call. Both were investigated like accidents, traced to the same design detail, and that detail was revised for the next bridge. The board also started a decision log, so that the next review would be able to see what people believed when they decided. DQ-LRN-03 · DQ-LRN-06 · DQ-LRN-08
Common mistakes
- Lessons noted, nothing changed. SOP-GOV-06
- Judging decisions by how they turned out. DQ-LRN-03
- Another rule instead of a structural fix. PM-3
- Continuing because of what's already spent. OGV-ESC-01
- Closing actions without checking they worked. QMS-CAP-03
8. Start the cycle again
Adapt ends where Diagnose begins. The evidence gathered here becomes the starting point for the next diagnosis: a sharper gap statement, a better baseline, fewer untested assumptions and a clearer picture of which cause families matter in this organization. Each cycle should be faster and cheaper than the last, because the organization has learned how to change. PM-1 · DGN-DATA-02
Real changes rarely move through the stages in strict order; Support and Measure run in parallel, and a failed gate can send you back to Prepare. The cycle is a map, not a script. PM-20 · #64
For small organizations, Adapt is a habit more than a process: a short review after each significant piece of work, one list of changes with names against them, a monthly look at whether last month's changes worked, and the willingness to stop what isn't working. Those four habits, kept up for a year, change an organization more than any transformation programme. PM-23 · DQ-LRN-04
The checklist. Review under a just culture, during the project as well as after. Judge process apart from outcome. Look for several causes. Investigate near misses. End every lesson in a change, a recorded decision not to, or a test. Prefer structural fixes. Track recommendations to closure where the authority sits, and check the fix worked. Treat your own changes as changes. Agree stop rules, compare stopping with finishing, and make stopping honourable. Carry lessons from projects into the enterprise. Then start again at Diagnose.