Decision Log

Why decisions don't stay decided

Halfway through a program I was running, a senior director joined a steering meeting and asked, with apparent earnestness, why we'd chosen vendor A over vendor B. The room went quiet. Six of us had been part of the decision. It had been made eight months earlier. None of us could defend it on the spot.

We lost a week reconstructing the answer. The team lost faith in itself for slightly longer. That program is the reason I keep a decision log.

"Decisions don't take care of themselves. Programs that act like they do end up making the same decisions twice. Or three times. Or five."

Most PMs resist logging decisions because it feels like make-work. The decision is fresh, everyone remembers it, why write it down? The answer is that "everyone remembers it" decays at a rate most PMs don't appreciate. Six months later, half the room is different people. A year later, the original sponsor is gone. Two years later, the decision shows up in a strategy review and nobody knows why it was made.

The five-field core

The format is short. Five fields. The whole entry fits in a paragraph.

1. Date. When the decision was made. Anchors the reasoning to a moment in time.
2. The decision itself. One sentence. Specific. "We chose vendor A" is not a decision. "We chose vendor A on a three-year contract at $1.4M annually" is.
3. Options considered. Named, not "we looked at alternatives." One line on why each was rejected.
4. Rationale. Why this option, in plain language. Tie it to an OKR or charter goal if you can.
5. Owner. One name. Not "the team." Not "leadership." A person who owns the call if it goes wrong.

That is the whole core. A four-sentence record of a decision is worth a thousand times more than a perfectly remembered version of the decision in the PM's head, because the four-sentence version survives org changes, sponsor changes, and the PM's own forgetfulness.

The director move: tie every decision to an outcome

Decisions made in service of an outcome are durable. Decisions made in service of nothing in particular are perpetually re-litigable. A decision entry that says "we chose vendor A because they had the lowest TCO" is a decision in search of an objective. A decision entry that says "we chose vendor A because lowest TCO directly serves OKR Q3-2: reduce platform run-rate by 25%" is a decision anchored to something.

When the OKR shifts, the decision can be honestly revisited. When the OKR holds, the decision holds. The OKR is the load-bearing wall. The decision is what's hanging on it.

Building a decision log in Excel

A decision log lives or dies on how long an entry takes. Ninety seconds and people write them. Four minutes and they stop by week three. Most of the ninety seconds should be thinking, not formatting, which means the sheet has to do the clerical work. Here is how the decision log Excel template is built.

Make it a Table first. Select the header row and one row of data, press Ctrl and T. That one step buys three things you would otherwise build by hand: filter dropdowns on every header, formulas that auto-fill when someone types a new row at the bottom, and structured references that do not break when the log grows from 40 rows to 400. Then click A4 and use View › Freeze Panes so the headers stay put.

Date stamping, and the mistake almost everyone makes. Do not put =TODAY() in the date column. TODAY is volatile: it recalculates on every open, so a log of thirty decisions made over eight months will all read as today's date the next time anyone opens the file. That is not a cosmetic bug. It destroys the only thing the log is for. Press Ctrl and semicolon instead, which types a static date into the cell and never touches it again. If you want the date locked harder, format the column as Date and protect it after each weekly review.

Auto-numbering. Decisions get referenced in emails and steering decks, so they need an ID:

="DEC-"&TEXT(ROW()-3,"000")

With the header on row 3, the first entry lands on DEC-001. Inside a Table this fills itself down forever.

The flag for the entry that is not really an entry. The most common failure is a decision written down with no rationale, which is a record that a thing happened, not a record of why. Put this in a checker column:

=IF(AND($C4<>"",$F4=""),"Missing rationale","")

Then back it with formatting. Select A4:J400, Home › Conditional Formatting › New Rule › Use a formula, and enter =AND($C4<>"",$F4="") with an amber fill. The whole row goes amber. Dollar signs on the columns, bare row number, so one rule covers the block. Add a second rule for review dates that have come and gone: =AND($H4<>"",$H4<TODAY(),$I4<>"Closed") in red. A decision with a 90-day review trigger that nobody ever triggered is how programs end up carrying a call made under conditions that stopped being true.

Status as a dropdown, not free text. Select the status column, Data › Data Validation › Allow: List, Source: Active,Superseded,Reversed,Closed. Four words. Free-typed statuses ("still good?", "mostly active") make every count formula lie.

Filtering by owner. Because the range is a Table, Insert › Slicer gives you a one-click owner filter you can put above the sheet, which is the fastest way to walk a decision review with one person. Behind it, a small summary block counts open decisions per owner:

=COUNTIFS($G$4:$G$400,$L4,$I$4:$I$400,"Active")

Linking a reversal to what it reversed. Keep a "supersedes" column holding the prior ID, and pull the old decision text next to the new one so the pair reads as a story:

=IFERROR(INDEX($C$4:$C$400,MATCH($J4,$A$4:$A$400,0)),"")

Excel and Google Sheets. The .xlsx opens in both. IF, AND, COUNTIFS, INDEX, MATCH, IFERROR, TEXT, and ROW are identical, and the conditional formatting rules and the status dropdown import cleanly. Two differences worth knowing. Ctrl and semicolon still inserts a static date in Sheets, so the important habit survives. Slicers do not: Sheets slicers only attach to pivot tables and charts, so the equivalent for a decision log is Data › Create a filter view, one saved view per owner, which has the useful property of not changing what anyone else sees.

A worked decision log example

Four entries from one program, five months apart, written the way they were meant to be found.

At a glance, this log answers the question that ambushed me in a steering meeting years ago. Why vendor A? Row one, with the two rejected options and the number that decided it. And the DEC-002 and DEC-004 pair is the part people underrate: the reversal did not erase the original call, it dated it and explained what changed. Anyone reading it in 2028 can see that the team was right in April and right again in June, for reasons that are visible.

Four rows. Maybe six minutes of typing, spread across five months. That is the entire price of not re-litigating your own program.

Questions PMs ask

How is this different from a meeting-notes archive?

Meeting notes capture what was said. A decision log captures what was decided, why, and who owns it. The two are complements: meeting notes are searchable history; the decision log is the small subset of that history that future you, or a new sponsor, will actually need.

Do I really need 14 worked examples?

The hard part of a decision log is not the format. It is recognizing which decisions are worth logging. The 14 entries span scope cuts, vendor calls, architectural trade-offs, and escalations, so you can pattern-match against your own program instead of starting from a blank row.

What if my decision turns out to be wrong six months later?

The log gets a new entry that supersedes the old one, with a date and a reason. The old entry stays, with its status changed to "reversed" or "superseded." Three years later, that supersession history is the most valuable thing in the log: it shows both the original reasoning and the reason it changed.

Excel or Google Sheets?

Both. The template is .xlsx and opens cleanly in Google Sheets. Conditional formatting carries over.