Part 5 — Templates & Tools
The four artefacts that keep the framework running
Four working templates carry the framework. None of them is complex; the value is in keeping them current rather than in the format itself.
The templates
- Risk register — ID, category, description, likelihood (1–5), impact (1–5), score, owner, mitigation, due date, status. The single source of truth from Part 2.
- RAID log — risks, assumptions, issues, and dependencies tracked together for the whole project, reviewed alongside the risk register so nothing falls between them.
- Pre-mortem checklist — before kickoff and before each stage gate, ask: “It’s twelve months from now and this failed — why?” Log every plausible answer as a risk.
- Stage-gate checklist — business case validated, data readiness confirmed, compliance mapping complete, change-management plan in place, rollback plan defined. All required before funding the next phase.
Tools
None of these four artefacts need dedicated software to start. For most SMB-sized rollouts:
- Start with one shared spreadsheet. A single Google Sheet or Excel file, one tab per artefact — register, RAID log, pre-mortem log, stage-gate checklist — shared with the steering committee from Part 4. That is enough for the entire life of a single pilot.
- Graduate to a lightweight tracker (Notion, Airtable, or your existing project tool) once you’re running more than one AI project at a time, or once the register needs to be filtered and cross-referenced by category, owner, or stage across projects.
- Only move to a dedicated GRC platform once the volume of tracked risks, vendors, or regulatory mappings makes a spreadsheet genuinely unmanageable — for most SMBs this playbook targets, that point never arrives.
- Whatever you use, one rule matters more than the tool: it has to be the single copy the steering committee actually opens live in the meeting from Part 4, not a slide exported from it. A register nobody opens live is the “filed and forgotten” failure Part 2 already warns about.
Worked example
One filled-in row per artefact, so the fields aren’t abstract.
Risk register
| ID | Category | Description | L | I | Score | Owner | Mitigation | Due | Status |
|---|---|---|---|---|---|---|---|---|---|
| R-014 | Data | Customer records used for the pilot haven’t been checked for consent basis | 3 | 4 | 12 | Data owner (Sana) | Run consent audit before build starts | Oct 3 | Open |
RAID log
Same register entry, plus:
- Assumption — “marketing data is clean enough to skip a full audit” (owner: sponsor, to be tested by Oct 3).
- Dependency — the pilot can’t start until the consent audit closes.
Pre-mortem checklist
“It’s twelve months from now and this failed — why?” → answer logged: “We never got sign-off on the data source, so the pilot stalled at week 3 waiting on legal.” → becomes risk R-014 above.
Stage-gate checklist (before funding Phase 2)
Business case validated ✓ · data readiness confirmed ✗ (blocked on R-014) · compliance mapping complete ✓ · change-management plan in place ✓ · rollback plan defined ✓. One open item is enough to hold the gate.
Ownership & cadence
Each artefact ties back to the RACI and review cadence set in Part 4.
| Artefact | Owner | Updated | Reviewed |
|---|---|---|---|
| Risk register | Risk owner | As risks are identified | Every steering meeting (Part 4) |
| RAID log | Project lead | Weekly during build | Monthly steering review |
| Pre-mortem checklist | Sponsor + technical lead | Once per stage gate, before kickoff | At the stage gate itself |
| Stage-gate checklist | Sponsor | At each gate | Gate decision meeting |
A register updated only when someone remembers is the exact failure Part 2 warns against — “a register written once and filed is worse than no register at all.” The same discipline applies to all four artefacts here, not just the register.
Where these break down
- Risk register used as a one-time intake form instead of a living document — filled in at kickoff, never revisited at the monthly reviews Part 4 sets up.
- RAID log duplicated as a second risk register instead of tracking what the register doesn’t: assumptions nobody has tested yet, and dependencies that block a risk from being closed.
- Pre-mortem run once at kickoff and never repeated — Part 2 calls for it before kickoff and before each stage gate, but it’s the step teams skip once momentum makes failure feel unlikely.
- Stage-gate checklist treated as a formality to rubber-stamp rather than a real hold point — an unticked box waved through under deadline pressure is the checklist failing at the one moment it exists for.
How the five parts fit together
Part 1 named the seven categories that derail AI projects. Part 2 turned that into a scored, living register. Part 3 gave each category its own mitigation, not a generic one. Part 4 put three named people and a fixed cadence around the whole thing so it doesn’t stop running after week one. These four artefacts are where all of that lives day to day — the register is the one to build first, because everything else here either feeds it or reads from it. Build it, put it in front of the steering committee from Part 4, and the rest of the framework has somewhere to run.
It also connects outward: the governance register in the AI Governance Playbook Series is where the compliance side of the same risks lives, and the dashboard in Measure Value, Risk, Costs & KPIs is where you watch them after go-live.