Each example follows one team from the guide, risk assessors running an AI pilot whose decisions still wait on legal review and three signatures.
The Outcome Map puts the funded outcome on one page
The page answers what the team is trying to accomplish, why, and how it will know. It then sorts current work by whether it moves toward the outcome, away from it, or sideways. Review it monthly. Everyone on the team should be able to name the outcome.
- What are we trying to accomplish?
- Customers get a risk decision as soon as the assessment is done.
- Why?
- After the AI finishes its assessment, customers wait on legal review and three signatures.
- How will we know?
- The time from application to decision drops.
Toward the outcome
- Agree with legal on which cases it can sample
- Find out whether one signature can approve low-risk cases
Sideways
- Make the model score cases faster
Away from the outcome
- Add a manual check of every AI recommendation
The Workaround Log records how people route around failing systems
The log tracks how people get work done when official systems fail them, through sticky notes, spreadsheet macros, and swivel-chair integrations, where a person copies data between systems by hand. Each entry records what needed to happen, what blocked it, and how the team routed around it. Every entry points to a step that AI might take over.
| What needed to happen | What blocked it | How the team routed around it |
|---|---|---|
| Send a case to legal | The case system has no legal queue | Assessors email legal a spreadsheet of cases each morning |
| Get the third signature | The approving manager is away | A sticky note on the file asks a deputy to sign |
| Put the AI score in the case record | The model and the case system don't connect | An assessor copies each score by hand |
The Responsibility Matrix compares nominal and actual owners
The matrix lists each piece of work with its nominal owner, its actual owner, and the gap between them. Read the gap column first. It lists work no one is formally responsible for. Flag every row with a gap for correction.
| Work | Nominal owner | Actual owner | Gap |
|---|---|---|---|
| Deciding which cases need legal review | Legal department | Each assessor, case by case | No written rule |
| Approving a decision | Three signers | The first signer; the other two sign without reading | The second and third signatures only add delay |
| Checking the model's accuracy after launch | The vendor | Nobody | No owner |
Friction Analysis sorts the workarounds by cause
Once a quarter, read across the Workaround Log and sort the patterns by structural cause, such as procurement, authority, capacity, dependency, or accountability. For each pattern, decide whether to route around it or push through it.
| Pattern | Where it shows up | Steering decision |
|---|---|---|
| Authority | ||
| Every decision needs three signatures | The sticky-note signatures; two signers who do not read | Push through: propose one signature for low-risk cases |
| Dependency | ||
| The model and the case system don't connect | The hand-copied scores | Route around until the vendor contract changes |
| Accountability | ||
| No one owns model accuracy | The empty row in the Responsibility Matrix | Push through: name an owner |
The Progress Protocol asks three questions each week
The protocol runs on three schedules.
- Every week: What moved toward the outcome? What blocked us? What workaround emerged?
- Every month: Which blocker keeps coming back?
- Every quarter: Are we closer to the outcome than 90 days ago?
Answer the weekly questions in writing during the standup slot. Over time the answers become the team's record of what it learned.
- What moved toward the outcome?
- Legal agreed to sample low-risk cases for two weeks.
- What blocked us?
- The case system cannot route cases to legal without a vendor change.
- What workaround emerged?
- Assessors started marking low-risk cases in the email subject line.