Skip to content

Decision Log

At a glance

  • Purpose: Record what was decided, by whom, when, and why — so decisions are not re-litigated, and new team members can understand the reasoning rather than only the outcome.
  • Use it when: Continuously, for any decision that is expensive to reverse or that someone might reasonably question later. Not for routine choices.
  • Owner: Whoever chairs the meeting where the decision is taken; the project manager keeps the log.
  • Related: Module 11 · Module 12 · Lab 22
  • Spreadsheet version: csv/decision-log.csv

How to use this template

  1. Log the reason and the options rejected. The rejected alternatives are the expensive part of a decision to rediscover, and their absence is why projects re-debate settled questions.
  2. Record the decider: a role and a person. "The team agreed" cannot be asked to explain itself.
  3. Note the reversibility and cost of reversal. Cheap-to-reverse decisions need less analysis, and saying so prevents disproportionate process.
  4. Record what the decision depended on — the assumptions or evidence — so that when they change, the decision can be revisited deliberately rather than accidentally.
  5. Include decisions already implicitly taken when you start the log: technology already chosen, scope already excluded. Otherwise the log documents only the second half of the project.

Field descriptions

Column What goes in it Watch out for
ID Stable reference (DEC-012) Decisions described in meeting minutes only
Date When the decision was made The date it was logged
Decision One sentence, in the imperative A discussion summary
Options considered The realistic alternatives A single option recorded
Reason Why this option, with evidence "Best practice" as a justification
Decided by Named person or body "Management" or "the team"
Depends on The assumptions or evidence relied on Unstated dependencies
Reversibility Cost or difficulty of changing course Assumed irreversible, so over-analysed
Affects Artefacts or baselines changed Decisions with no recorded consequence
Review trigger The event that would reopen it Decisions that can never be revisited

Blank template

# Decision Log — [Project name]

| | |
| --- | --- |
| **Log owner** | [Who maintains this] |
| **Scope of the log** | [Which decisions are logged — e.g. anything affecting baselines, interfaces, or architecture] |

| ID | Date | Decision | Options considered | Reason | Decided by | Depends on | Reversibility | Affects | Review trigger |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| DEC-001 | [YYYY-MM-DD] | [One-sentence decision] | [A / B / C] | [Why] | [Named person or body] | [Assumption or evidence] | [Cheap / costly] | [Documents or baselines] | [Event] |

## Decisions taken before this log existed

| Decision | When (approximate) | Evidence of it | Still valid? |
| --- | --- | --- | --- |

## Superseded decisions

| ID | Superseded by | Date | Reason for change |
| --- | --- | --- | --- |

Worked example

Two decisions from the admission portal, invented for teaching:

ID Date Decision Options considered Reason Decided by Depends on Reversibility
DEC-006 2026-03-18 Build the eligibility rules engine after written sign-off of the rule set A: build now from the draft rules; B: wait for sign-off; C: build a configurable engine now B lacks a working rules engine before testing (7 days, on the critical path), but A was rejected because the draft contained two unresolved boundary cases that would have produced rework greater than 7 days. B chosen; C recorded for a future release Steering committee (chair: sponsor) Admissions office can sign off within 10 working days Costly — sequencing change after sign-off
DEC-007 2026-03-25 Retention period will be configurable rather than hard-coded A: hard-code once confirmed; B: configuration parameter A depends on a confirmation that has not arrived (see I-005). B costs 3 days and removes a compliance exposure Project manager, within delegated authority Configuration remains acceptable to the records office Cheap — parameter can be frozen later

Note how DEC-006 changes the schedule and therefore must appear in the change log and in the baseline update record. A decision log that is not connected to baselines and changes becomes an interesting diary; connected, it is what allows the project to explain its own history. DEC-007 also shows the value of recording the dependency: the decision is correct only while the retention question is open, and its review trigger says so.

Common mistakes

  • Decisions recorded in meeting minutes only. They are unfindable three weeks later, and the reasoning is lost with them.
  • Only the outcome, not the alternatives. This guarantees the same debate will happen again.
  • No named decider. Nobody can be asked to justify it, so it will be challenged by whoever is loudest.
  • Retrospectively rewritten reasons. A log whose entries are adjusted to match outcomes stops being evidence of anything.
  • Logging everything. Routine choices do not need entries, and a log nobody reads is the result.
  • No link to changes and baselines. Decisions that alter scope, schedule, or cost are only half recorded until the change process reflects them.
  • Assuming reversibility where there is none. Recording reversibility honestly is what tells you how much analysis a decision deserves.