Discovery & analysis
Decision log
Keep a running decision log — what, by whom, when, on which grounds. Critical when there is staff turnover, late questions and steering-group debates.
Updated Jan 23, 2026
Discovery · 3.8
Why continuously (not only at the end)
Decisions are only valuable if you can explain them later. Three months after go-live someone asks “why did we configure this this way?”. Without a log = darkness, rework discussion. With a log = click through and know. Especially critical during staff turnover (PM, steering group, sponsor) — otherwise context disappears with the people.
What do you deliver?
Decision log
One document or table with all significant decisions, chronologically.
Clear trigger rule
When does something become “significant” and go in the log? Not everything, but more than you'd think.
Owner of the log
One person (PM or analyst) who adds at least one entry per workshop.
Workable format
Notion, Confluence, shared Excel, SharePoint list — whatever works for your team.
When a decision is “significant”
In the log
- Choosing between alternatives (e.g. workflow A vs B)
- Scope exclusions (Won't list)
- Naming choices (department names, classification names)
- SLA tiers and escalation rules
- Ownership (who is the 'A')
- Financial rules (cost allocation, cost centres)
Not in the log
- UI styling, field order
- Trivial agenda items
- One-off technical workarounds
- Operational agreements (captured in manuals)
Steps
- 1Choose tool and template — shared location accessible to the steering group and project team. See template below.
- 2Assign one owner — usually the PM or business analyst. They own the log.
- 3Update during every workshop — last 5 minutes of a session: “which decisions did we make?”. Log immediately.
- 4Per entry: note alternatives — not just “we chose X”, but also “Y and Z were on the table, reasons for rejecting were …”.
- 5Categorise with tags — “Master data”, “Workflow”, “Finance”, “Security”. Makes the log searchable later.
- 6Revalidate on doubt — if someone later asks “are you sure?”, use the log to confirm or deliberately change (with a new entry).
- 7On change: new entry — don't overwrite the old one. “Decision #12 replaces #5 because …”. The audit trail stays intact.
Template — Decision log
| # | Date | Topic | Decision | Alternatives (rejected) | Reasoning | Owner | Tags | Status |
|---|---|---|---|---|---|---|---|---|
| 1 | 2026-01-15 | Location hierarchy | Geography → Building → Floor → Room | Flat (Building only) | Report occupancy per floor | Head of Facility | Master data | Approved |
| 2 | 2026-01-18 | Approval > €500 | Manager must approve | Auto-approve up to €1000 | Compliance + budget control | CFO | Finance, Workflow | Approved |
| 3 | 2026-02-03 | Self-service portal | Phase 1 tickets only, no reservations | Both at once in phase 1 | Capacity + change load | Sponsor | Scope | Approved |
| … | … | … | … | … | … | … | … | … |
Best practices
→ Write with the future in mind
Imagine: a colleague reads this in 18 months without context. Will they understand?
→ Link to evidence
Add a link to the process map, RACI or pain-point list that justifies the decision.
→ Use for change requests
Someone wants to change something? Point to the original entry, force the reasoning.
→ Keep openly visible
Don't hide it in an unreachable folder. Central, findable, readable by every stakeholder.