Decision Records & Rationale Templates

Purpose

This set of templates helps teams capture why a decision was made, which assumptions mattered, who owns follow‑up, and how outcomes will be measured. Good decision records turn choices into learning signals instead of mysteries—without becoming bureaucratic paperwork. Use the short template for operational choices and the extended template for strategic or high‑risk decisions.

How to use these templates

Prefer the shortest template that still preserves the signal you need. Fill a record at the time the decision is made (or as close as possible). Link the record to the project or ticket, attach key evidence, and schedule a review or outcome check. Treat records as living notes that may be updated with outcomes, mitigation changes, or declassified context over time.

Short Decision Record (use for routine decisions)

1. Issue / Question — One sentence describing the decision to be made.
2. Decision — The actual choice or action to be taken.
3. Owner — Who is accountable for implementing and tracking outcomes.
4. Rationale (Why) — Key reasons, constraints, and trade‑offs (3–5 bullets).
5. Critical Assumptions — Which assumptions must hold for the decision to succeed.
6. Review Date / Outcome Check — When to revisit the decision or check outcomes.
7. Related Artifacts — Links to tickets, data sources, models, or approvals.

Short example:

Issue: Increase backup frequency for DB cluster. Decision: Move backups from daily to twice daily for 90 days. Owner: DB Team Lead (A. Kim). Rationale: Recent incidents revealed 24h RPO exposes more risk; storage cost increase is acceptable. Assumptions: No significant performance impact; retention policy unchanged. Review: 2026‑12‑01. Related: Incident #457, storage cost estimate.

Extended Decision Template (use for strategic, high‑risk, multi‑stakeholder decisions)

1. Title — Short, searchable title.
2. Date — When the decision was recorded.
3. Decision Owner(s) — Primary accountable person(s) and backup.
4. Decision — Clear statement of the chosen option.
5. Scope & Boundaries — What the decision covers and what it explicitly excludes.
6. Context & Background — Brief history, drivers, and constraints.
7. Options Considered — Short pros/cons and estimated costs for each option.
8. Trade‑offs & Risks — Explicit trade‑offs and top risks with mitigation plans.
9. Key Assumptions — Assumptions that materially change outcomes if false.
10. Expected Outcomes & Metrics — What success looks like and how to measure it (KPIs, targets, time horizon).
11. Implementation Plan & Owner — High‑level plan, milestones, and owners for steps.
12. Review / Revisit Plan — Dates and criteria for re‑evaluation.
13. Confidentiality Notes — What context should remain private and why.
14. Related Links & Attachments — Models, data, approvals, legal reviews.

Extended example (summary): Decision to adopt Vendor X for payments. Options considered: Vendor X (integrates, moderate cost), Build in‑house (high cost, longer time), Vendor Y (cheaper, fewer integrations). Chosen: Vendor X. Key assumptions: Vendor SLA holds; integration requires 2 months. Success metrics: reduce payment failures by 90% within 6 months; lower processing cost by 10% in year 1. Review: 2027‑03‑01. Owner: Head of Payments.

Pre‑mortem Template (before a risky decision)

1. Decision — Brief description.
2. Date
3. Imagine failure — Ask: “This decision failed spectacularly. What happened?” (List 3–6 plausible failure modes.)
4. Contributing Factors — For each failure mode, list causes and early warning signals.
5. Mitigations — Immediate steps to reduce likelihood or impact.

Pre‑mortems help surface hidden assumptions and force stronger mitigations before committing.

Post‑mortem / Outcome Attachment (after the decision)

1. Decision & Date
2. Outcome Summary — What actually happened (quantified where possible).
3. What Went Well / Not Well — Short analysis.
4. Assumption Check — Which original assumptions held? Which failed?
5. Lessons & Actions — Concrete next steps, owners, and deadlines to capture learning.
6. Record Updated? — Yes/No and date.

Folder & Naming Conventions (keep records discoverable)

• Store decision records in a single searchable collection or a predictable folder path per team (e.g., /Org/Payments/Decisions/).
• Filename pattern: YYYYMMDD <Team> <ShortTitle> <DecisionType> (e.g., 20260901_Payments_ChooseVendorX_Strategic.pdf).
• Add metadata tags: team, decision_type (operational/strategic/compliance), owner, review_date, related_project.
• Ensure links to tickets, contracts, or models are embedded rather than only referencing where the artifact might be.

Best Practices & Common Pitfalls

• Capture the record when the decision is made — not weeks later.
• Prefer clarity over completeness. A short, clear record is better than a long, vague one.
• Protect sensitive sections (legal, personnel) while keeping non‑sensitive learning open and searchable.
• Assign a visible owner and a review date—records without follow‑up become dead artifacts.
• Do not expect templates alone to create learning—combine records with outcome checks, dashboards, and team rituals that surface learning.

When not to record

Minor tactical choices that are routine and reversible do not need formal records. Instead, capture learning in meeting notes or a shared log if an unexpected pattern emerges.

Next Steps & Suggested Integrations

Start with the short template; use the extended template for decisions that affect multiple teams, budgets, compliance, or customer outcomes. Consider pairing records with an outcomes dashboard that tracks the metrics named in the record.

Template Files

Attach or copy these template variants into your team toolkit as editable documents (short template, extended template, pre‑mortem, post‑mortem). Name them consistently so they can be acquired and tailored as part of a collection or toolkit.

Protecting Privacy & Sensitive Context

When records include personnel, legal, or customer data, redact sensitive details or store that portion separately with controlled access. Keep the learning‑oriented parts (assumptions, trade‑offs, outcomes) accessible to appropriate audiences to preserve organizational memory.