A decision log is a short record of the choices that change a project. It should tell a future reader what was decided, why that choice made sense at the time, what tradeoff was accepted, and what would justify reopening the question.
It is not a transcript. It is not a folder full of meeting notes. And it should not turn a small project into a corporate reporting exercise.
The useful version is compact enough to update while the decision is still fresh and clear enough to stop the same debate from restarting every few weeks.
What a decision log should protect
Projects lose more than files when time passes. They lose context. A creator remembers that a feature was cut but forgets the constraint that forced the cut. A team remembers the chosen vendor but not the risk they accepted. A founder sees an old deadline and assumes it was careless, even though it may have been tied to information that later changed.
A decision log protects that missing context. It answers four questions:
- What choice did we make?
- What was true when we made it?
- What did we give up or accept?
- What happens next?
Microsoft's engineering decision-log example uses a concise set of fields for the decision, date, alternatives, reasoning, decision maker, and required work. That is a useful baseline. Smaller projects can go one step further by adding a review trigger, so a settled choice does not become a permanent rule by accident.
Which decisions belong in the log?
Do not record every preference. Record a choice when forgetting its reasoning would create real friction later.
A decision belongs in the log if at least one of these is true:
- It is expensive to reverse. Changing it later would cost meaningful time, money, trust, or rework.
- It changes downstream work. Other tasks, people, files, or deadlines now depend on it.
- It is likely to be debated again. The options were close enough that someone will reasonably ask why one won.
- The context is easy to lose. The choice depends on a temporary constraint, incomplete evidence, or a narrow window.
- Someone must own the consequence. The decision creates an action, handoff, approval, or boundary that needs a named owner.
Color choices, one-off wording edits, and reversible layout preferences usually do not need a row. Scope cuts, pricing rules, publication cadence, vendor selection, technical direction, and commitments to another person usually do.
A seven-field decision log template
A spreadsheet, shared document, project page, or plain text file can all work. The tool matters less than using one dependable location.
| Field | What to record |
|---|---|
| Date | When the decision became active, not when the discussion started. |
| Question | The decision that needed an answer, written in one sentence. |
| Decision | The chosen direction in direct language. |
| Context | The facts, constraints, or evidence that shaped the choice. |
| Alternatives and tradeoff | The serious options considered and the cost accepted by choosing this one. |
| Owner and next action | Who carries the decision forward and what changes now. |
| Review trigger | The event or evidence that would justify revisiting it. |
The review trigger is more useful than a vague promise to "check later." A date can be appropriate, but an event is often clearer: reopen when the first ten customer interviews are complete, when the supplier changes terms, when the project exceeds its time budget, or when a required integration becomes available.
Write the decision so it survives context loss
A weak entry says: "Decided to delay the launch."
A useful entry says: "Move the public launch from August to September so the onboarding flow can be tested with the current five-person pilot. Accept one month of delay to reduce support risk. The project owner will complete the pilot and summarize the issues. Reopen the date if the pilot has fewer than three active participants by August 15."
That example does not pretend the choice was perfect. It preserves the cause, the tradeoff, the owner, and the condition that could change the plan.
Use plain language. If the entry needs several pages to explain the decision, keep the log row short and link to the deeper analysis. The log is an index to judgment, not a warehouse for every document.
Use a threshold before making the entry
The biggest risk is not an imperfect template. It is making the system so heavy that nobody uses it.
Before logging a choice, run a simple threshold:
- Would a reasonable person ask "why did we do this?" in three months?
- Would forgetting the answer cause rework, conflict, or a poor reversal?
- Does the decision create an owner, dependency, or measurable consequence?
If the answer is no to all three, keep moving. If any answer is yes, write the entry while the reasoning is fresh.
Keep the log connected to the work
A decision record becomes useful when it changes behavior. After writing an entry:
- Link the affected work. Add the relevant task, brief, contract, draft, or source.
- Communicate the outcome. Send the decision, not the full debate, to the people who need it.
- Update the plan. Change the owner, scope, sequence, or deadline that the choice affects.
- Preserve replacements. If a later decision supersedes the old one, mark the old entry as replaced and link the new entry. Do not erase the trail.
A weekly review that produces decisions is a natural place to scan open triggers. The log should not become another inbox. It should surface only the choices that need action or fresh evidence.
Separate choosing from documenting
A decision log cannot make a hard choice for you. It records the judgment after the relevant people have made it.
If the problem is choosing between credible paths, use the tradeoff and stopping-rule approach in this guide to deciding between two good options. If everything appears equally urgent, first apply a consequence and dependency filter.
Then write the result. Do not use documentation as a respectable-looking way to postpone the call.
Avoid four common decision-log failures
Logging conversations instead of decisions
Discussion belongs in notes. The log gets the resolved choice and the context required to understand it.
Writing rationale as certainty
Record what the evidence supported at the time. Do not rewrite uncertainty into confidence after the fact.
Using review dates with no question
"Review in 30 days" creates a meeting. "Review when returns exceed the agreed threshold" creates a decision condition.
Deleting choices that changed
A reversed decision is still part of the project's history. Mark it superseded, explain what changed, and link the replacement.
Create the first entry in ten minutes
Open one file and name it Decision Log. Add the seven fields. Then capture the most recent project choice that would be difficult to explain from memory alone.
Keep the first entry short. The standard is not completeness. The standard is whether someone can act without reconstructing the entire debate.
Defaults can handle the smaller choices. A repeatable calendar, workspace, or personal uniform can remove decisions that do not deserve fresh attention. If a simple everyday layer fits that role, the live Standard Issue Tee is one option. It does not make the important decisions. It leaves them to you.
Build the log, record the next consequential choice, and return to the work. For more practical frameworks, visit The Self Made Journal.
0 comments