A practical framework for treating documentation as part of service control, knowledge retention, auditability, recovery and project-to-BAU transition rather than administrative overhead.
Process map
PolicyWhat must
be true
be true
StandardHow consistency
is achieved
is achieved
Procedure / SOPHow work
is performed
is performed
RunbookHow services
operate / recover
operate / recover
As-BuiltWhat was actually
implemented
implemented
Decision RecordsWhy choices
were made
were made
HandoverWho owns it
in BAU
in BAU
MaintainReview / change
keep current
keep current
Different documents solve different problems
- Policies define required outcomes and guardrails.
- Standards translate policy into consistent technical or operational expectations.
- Procedures and SOPs describe repeatable work.
- Runbooks support operation, incident response and recovery.
- Technical and as-built documentation record what was actually implemented.
- Architecture and integration diagrams show dependencies and system boundaries.
- Decision logs, RACI and RAID preserve delivery context and accountability.
- Handover material establishes the BAU owner, support model and remaining backlog.
Why documentation is a control
- It reduces key-person dependency.
- It makes operational work repeatable.
- It improves support and recovery when the original implementer is unavailable.
- It supports audit, assurance and evidence requirements.
- It enables safer outsourcing, insourcing, M&A integration and divestment.
- It makes project-to-BAU transition real rather than ceremonial.
Avoid shelfware
- Write for the person who will actually use the document.
- Keep ownership and review dates explicit.
- Update documentation as part of change/release processes.
- Prefer diagrams, checklists and concise operating instructions where they communicate more clearly than narrative.
- Retire obsolete documentation alongside the systems and processes it describes.
Minimum viable documentation
- For a new or materially changed service: owner, purpose, dependencies, access model, support path, architecture/as-built, recovery approach, known risks, vendor contacts and change history.
- For a policy or procedure: owner, scope, required actions, exceptions/escalation, evidence and review cycle.
Key lessons
- Documentation is an operational control, not an administrative afterthought.
- If nobody can use it during an incident, handover or audit, it is probably not the right documentation.
- Good documentation protects organisational knowledge when people, suppliers or platforms change.
- The best documentation is proportionate, owned and maintained.