A project decision log is a short, dated record of the choices that change the work. It should let a teammate answer five questions without reopening a meeting: What was the question? What did we decide? Why? What changes now? What would make us revisit it?
The best log is not a transcript or a second project plan. It is a memory system for choices, small enough to update while the decision is fresh and clear enough to guide the next action. That makes it useful for a founder, a small team, a student, or anyone carrying a project across several weeks.
Decision log vs. the other project documents
Most project confusion is not caused by a total lack of information. It comes from putting the right information in the wrong place. A meeting can contain the answer, but a person joining later should not have to search an hour of notes to find it.
| Document | What it holds | When to use it |
|---|---|---|
| Meeting notes | The discussion, questions, and context | When the conversation itself matters |
| Decision memo | The case for one important choice before it is made | When a decision needs evidence and a recommendation |
| Decision log | The final call, its reason, and what changes next | When a choice needs to stay visible after the conversation |
| Project plan or task list | The work required to carry the decision out | When the next actions need owners and dates |
A decision memo can help a group make a call. A log keeps the call from dissolving afterward. If you need the first document, read How to Write a Decision Memo That Moves Work Forward. Do not turn the two into one large page. The memo can hold the reasoning in depth. The log should make the outcome easy to find.
Use five lines for every meaningful decision
Start each entry with a simple header: decision ID, date, owner, and status. Then answer the five lines below. You can keep the whole entry short. Brevity is part of the design.
| Line | What to write | Useful test |
|---|---|---|
| Question | The choice that required a call | Could a person who missed the conversation understand what was being decided? |
| Decision | One active sentence stating the selected path | Does it say what will happen, not only what will not happen? |
| Reason | The facts, constraints, or trade-offs that carried the most weight | Would the reason still make sense three months from now? |
| Consequence | The scope, schedule, owner, or next action that changes | Can someone update the work because of this line? |
| Reopen trigger | The evidence or date that would justify revisiting the call | Is it specific enough to prevent routine second-guessing? |
1. Write the question, not the topic
“Website,” “launch,” or “vendor” is a topic. “Should the first release include the reporting screen?” is a decision question. The question gives the entry a boundary. It also stops a log from becoming a loose list of everything people discussed.
2. State the decision as a verb
Use language such as “We will ship,” “We will defer,” “We will choose,” or “We will stop.” A noun hides the owner and the action. A sentence makes the commitment visible.
3. Keep the reason selective
A decision log is not a place to preserve every opinion. Record the two or three conditions that explain the call: a fixed date, a dependency, a customer requirement, a quality bar, or a capacity limit. Name the rejected alternative when it prevents the same debate from returning.
4. Record the consequence
The consequence is the line most often missing from a weak log. If the team chooses one format, what gets removed from scope? If a review moves earlier, who prepares for it? If a task changes hands, where is the new owner recorded? The decision becomes useful when its effect reaches the working plan.
5. Add a real reopen trigger
“Revisit later” is not a trigger. Write the condition that would change the call: a failed test, a new requirement, a capacity change, or a date when the choice must be reviewed. If the decision should stand until the project ends, say that. A clear boundary protects attention without pretending every call is permanent.
Create the log while the decision is still warm
The timing matters more than the software. A perfect template filled in two weeks late is usually less reliable than a plain document updated before everyone leaves the conversation.
- Choose one home. Use the project space people already open. A log split between chat, email, meeting notes, and a private notebook is not a log. It is a scavenger hunt.
- Mark the decision boundary. Separate decided, open, and superseded. An unresolved question should not look like an approved direction.
- Capture the entry before the meeting ends. Read the decision sentence back to the people affected by it. Correct a wrong verb or missing constraint immediately.
- Connect the consequence to work. Link the next task, acceptance check, scope change, or handoff. If there is no consequence, ask whether the choice belongs in the log.
- Tell the people who need to act. The owner of the next step should not discover the decision by accident in a later status update.
A three-minute example
Imagine a small team deciding how much to include in the first release of a service. The entry could look like this:
Decision D-014 | 2026-08-18 | Owner: Sam | Status: Decided
- Question: Should the first release include both the core workflow and an advanced reporting view?
- Decision: Ship the core workflow first and defer the reporting view to the next release.
- Reason: The core workflow has a clear acceptance check. The reporting view still depends on a data definition the team has not agreed on.
- Consequence: Remove reporting from the first release scope, assign the data-definition question to Priya, and update the launch checklist.
- Reopen trigger: Reconsider when the data definition is approved or when a committed customer requirement makes reporting part of the first release.
That entry does not attempt to prove that the choice was perfect. It makes the choice inspectable. Someone can understand the call, carry it into the work, and challenge it later with new evidence instead of memory.
Keep the log useful after week four
Run a short review once a week. Look only for four things:
- Orphaned decisions: a decision exists, but no owner has carried its consequence into the plan.
- Stale decisions: the conditions changed, but the entry still reads as current.
- Repeated debates: the same question keeps returning because the original reason or reopen trigger is too vague.
- Hidden reversals: the team changed direction but edited the old entry instead of preserving the original call and marking it superseded.
Keep reversed decisions. They show how the work learned. Update the status, add the new decision, and link the two. A clean history is more useful than a record that makes every past choice look inevitable.
Turn the decision into proof
A log should not become another shelf where information goes to rest. After the call, give the consequence a visible test. Acceptance criteria make the work clear by defining what someone can check before a deliverable is accepted. The decision log tells you why that test belongs there.
For a workday that benefits from one less clothing choice, the Standard Issue Zip Hoodie is a straightforward layer: heavyweight fleece, a white embroidered mark at the chest, and a zip-up format. It is a uniform choice, not a productivity promise.
Find more practical systems in The Self Made Journal when the next part of the work needs a clear frame.
If a decision matters enough to change the work, give it a place where the work can find it. The point is not more paperwork. The point is fewer repeated conversations and a clearer next move.
0 comments