How to Build a Decision Log That Stops Re-Litigating Old Calls

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 told him we'd get back to him. What followed was a week of archeological work. Slack threads. Meeting notes. Email chains. Eventually we reconstructed the rationale well enough to explain it. He read the explanation, nodded, and said the choice still seemed reasonable. The program lost a week. The team lost faith in itself for slightly longer.

That program is the reason I now 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. The week we lost reconstructing vendor A was the visible cost. The invisible cost was bigger. From that meeting on, the team started second-guessing every decision that had been made in the previous year, because if we couldn't defend that one, what else couldn't we defend?

A decision log is a small document, maintained by the PM, that records every program-level decision likely to be re-asked. Not every decision. Only the ones that, six months from now, somebody is going to want to know the reasoning for. There are always more of these than the PM thinks at the time.

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. Six months from now, the date is how you separate "the original call" from "the meeting where we revisited it."

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, with the option to renegotiate at month 18" is.

3. Options considered

What you actually weighed. "We looked at alternatives" without naming them is fiction. List the options that were on the table, with one line on why each was rejected. Otherwise the entry reads like you picked the first idea anybody suggested.

4. Rationale

Why this option, in plain language. The rationale is the field that has to survive translation. Six months from now, somebody who was not in the room will read it. Write for that person.

5. Owner

One name. Not "the team." Not "leadership." A person who will own the call if it goes wrong. Consensus is not accountability. Even when ten people agreed, name the one whose call it was.

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.

Which decisions belong in the log

The hard part of a decision log is not writing it. The hard part is deciding what counts as a decision worth logging.

The filter I use:

• If the decision will affect work for more than a quarter, log it.
• If the decision will resolve a disagreement between two teams, log it.
• If the decision was hard, contested, or expensive to reach, log it.
• If the decision touches the charter, log it.
• If you can predict somebody will question this in 90 days, log it today.

Most program-level decisions, by this filter, are loggable. Most task-level decisions are not. The team can keep its own informal records of how it sequenced sprint work; that is not what a decision log is for. A decision log is for decisions that might come back. Most program decisions might.

When in doubt, log it. The cost of logging is two minutes. The cost of not logging is the week you spend reconstructing it later.

A worked entry

To make the format concrete, here is what a full entry looks like on the page.

Eight sentences. About ninety seconds of writing. The entry will sit in the log untouched for months. When a new sponsor walks in and asks "why didn't we ship mobile in Q1?", the answer is there, in language somebody who was not in the room can read.

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. The difference is visible in the log itself.

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% by end of fiscal year" 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.

Most PMs do not make this connection explicit. They make decisions, and somewhere in the back of their mind, they know which goal each decision serves. But the connection lives in the PM's head, which is exactly the wrong place for it. When the PM leaves, the connection evaporates. The decision is left dangling, attached to no outcome, ready to be re-litigated by anyone with a different view of priorities.

Make the connection explicit. Every entry gets a one-line tie to an OKR or a charter goal. If you cannot write the tie, you do not have a logged decision. You have a preference somebody once expressed.

Short log vs. deep log: pick the right ceremony

Not every decision needs the same level of ceremony. The mistake is using one format for everything.

Use both. The short entry covers 80% of program decisions. The deep entry exists for the 20% where the reversal criteria and review date will actually save you money. Trying to make every decision a deep entry is how the log becomes the work, instead of the byproduct of the work.

The mistakes that kill decision logs

• Writing the entry days after the decision. Memory fades within 48 hours. Rationale gets rewritten in a flattering direction. The list of options considered mysteriously shrinks to whatever the owner remembers. Log it within two days or accept that what you logged is historical fiction.
• Naming "the team" as the owner. Consensus is not accountability. A decision with no owner is a suggestion. Name one human, even when ten people agreed.
• Skipping options considered. The entry without options reads as "we picked the first idea." Three months later, somebody will reasonably ask "did we consider X?" and if the log says nothing, the only honest answer is "I don't remember."
• No reversal criteria on the entries that need them. Strategic and vendor decisions especially. "If X happens, we reopen" costs you 30 seconds and saves you a quarter.
• A log that nobody opens. The log is not for daily reading. The log is for the moment somebody asks. If the team does not know the log exists or where to find it, it cannot do its job. Link it from the program charter. Link it from the status report. Make it findable.
• Deleting old entries when decisions get reversed. The old decision stays in the log with a date and a reason for being overturned. The supersession is the most valuable entry in the whole log. Three years later it shows both the original reasoning and the reason it changed.

The cadence that holds

A decision log is not an artifact. It is a practice. The cadence that has worked for me across enterprise programs:

1. In the meeting: Capture the decision in real time. Five fields, two minutes, before the next agenda item. If you wait until after the meeting, you will not write it.
2. Within 48 hours: Clean up the entry. Confirm the owner. Add the OKR tie. Notify anyone in the "informed" column if you are using that field.
3. Monthly: Scan the log for entries with review dates due. Walk the list with the program lead. Mark each entry active, held, superseded, or reversed.
4. Quarterly: Run the 30-minute log review. Filter for the highest-stakes entries. Ask: is the rationale still load-bearing? Is the OKR still active? Has anything changed that should trigger a reversal? Most entries will be untouched. The ones that are not are exactly the ones worth surfacing.
5. On sponsor change: Pull the log out before the first 1:1. The new sponsor will ask about three or four decisions in their first month. Handing them the log entries before they ask is the move that buys the most credibility for the least effort.

The closer

A program is a long arc. Two years, three years, sometimes more. Across that arc, the team will turn over, the sponsor will change, the org will reorganize at least once. Every decision the program rests on is at risk during each of those changes, because each new arrival has the right to ask why something was decided the way it was decided.

The PMs who run long programs well are the ones who treat their decision log like a quartermaster's record. Mundane to maintain. Unremarkable when read. Indispensable in the moment somebody asks.

The cheap version of program continuity is a five-field entry, written in the moment, taking two minutes. Almost no one writes it. Almost everyone wishes, eventually, that they had.

That entry is the audit trail. That entry is the institutional memory. That entry is the program.

The program charter sets the goals the decisions serve. The roadmap shows the work the decisions shape. The RAID log captures the risks each decision absorbs. The decision log is what makes the rest of it durable when the people change.