Why most decision logs fail
The typical project decision log is a spreadsheet maintained by the PM, updated after meetings when time allows, and consulted only when something goes wrong. This model has a fundamental problem: the decisions most worth recording are the ones made in the most difficult and time-pressured environments — exactly the moments when the PM has the least time to write things down.
The second failure mode is completeness bias. PMs tend to record formal decisions made in structured settings — steering committee resolutions, change advisory board outcomes, formally tabled items. The decisions that cause the most problems on complex projects are the informal ones: the verbal agreement in a corridor, the "we'll just go ahead with that" from a business sponsor in a catch-up call, the assumption that became a commitment without anyone noticing the transition.
A decision log that only captures formal decisions is a record of the meetings that least needed documenting.
What a project decision log needs to contain
Every entry in a decision log should answer six questions. If an entry can't answer all six, it is incomplete.
What was decided?
The decision itself, stated as precisely as possible. Not "discussed the integration approach" — "agreed to use the existing API rather than build a new endpoint, based on the cost estimate presented by the technical lead." Vagueness in the decision statement is the primary cause of later disputes.
Who made it?
The person with the authority to make the decision, not just the person who said it aloud. If a business sponsor said "let's include that" in a meeting, the decision owner is the sponsor — not the PM who noted it down. The distinction matters when the decision is later contested.
When was it made?
Date and, where relevant, the specific meeting or context. A decision made in week 3 that isn't discovered to have been made until week 12 looks very different to a decision made in week 12.
What was the context?
A single sentence describing the situation that prompted the decision. This is the part most often omitted and most often needed — without context, a decision that made sense at the time looks inexplicable six months later.
What does it affect?
Scope, schedule, budget, resource, or process. Tagging the domain helps when you need to filter — "show me all decisions that affected the integration scope" is a query that saves hours in a dispute.
What is its current status?
Open (active and in force), implemented (delivered against), superseded (replaced by a later decision), or reversed (explicitly undone). A decision that has been reversed without a record of the reversal is a source of significant confusion.
The decisions most worth capturing
Not all decisions carry equal risk. The following categories deserve priority attention in any decision log:
The maintenance habit that works
A decision log maintained by batch — reviewed and updated weekly or after each formal meeting — will always be incomplete. The decisions that get missed are the ones made between the batch updates: the informal conversations, the quick calls, the Slack messages where something got agreed without a meeting being called.
The maintenance habit that works is immediate capture with deferred structuring. Immediately after any meeting or conversation where a decision was made — within the hour — write down in plain language what was decided, who decided it, and the context. This raw note doesn't need to conform to any format. It just needs to exist.
The structured entry — with tags, status, and domain — can be created from the raw note at a later point. What matters is that the raw note exists before the memory of the meeting fades.
For PMs using transcription tools — Plaud, Teams recording, Zoom — the capture step can be automated: the transcript goes into the record and the decision extraction happens from the text. This removes the dependency on the PM's attention and memory entirely.
How to use the decision log when a dispute arises
The PM who has maintained a complete decision log approaches a scope or delivery dispute with a fundamentally different posture. Instead of reconstructing events from memory and competing with the stakeholder's reconstruction, they can present a dated, attributed record of what was decided and when.
The most effective use of the decision log in a dispute is not confrontational — it is clarifying. Presenting the record as "here is what we documented at the time" rather than "here is proof you are wrong" shifts the conversation from a blame allocation to a shared examination of what actually happened. This is a more effective posture and produces better outcomes.
For PMs working in environments where they have responsibility without authority — where they coordinate outcomes but don't control resources or final decisions — the decision log is also professional protection. It shows that the PM was tracking, flagging, and escalating appropriately, regardless of what others decided to do with the information.
Decision log field reference
The following fields represent a complete decision log entry. Use this as a template for any format — spreadsheet, document, or dedicated tool.