Give decisions a place of their own
A project can have neatly organized files and still leave people unsure why the work took its current direction. The answer may be buried in a meeting note, a message thread, or someone’s memory. When the question comes up again, the team has to reconstruct the discussion instead of continuing the work.
A decision log is a short, searchable record of choices that shape a project. It is not a transcript of every conversation or a list of tasks. Its purpose is to answer a few practical questions: What did we choose? Why? Who was involved? Does the choice still apply?
Start with one document or table in the project’s shared workspace. Give it an obvious name, such as “Project decisions,” and link to it from wherever people normally enter the project. A familiar location matters more than a sophisticated format. If finding the log requires its own search, it is unlikely to become part of everyday work.
Record enough context to make a choice understandable
Each entry needs a date, a brief decision, and a reason. Add the person or group responsible when that would help someone follow up later. If the choice depends on a condition, state it plainly: “Use this process while the team is working from one shared queue.” That detail makes it easier to recognize when a decision needs another look.
For example, “Use a single intake form for new requests” is more useful when paired with “Requests were arriving through several channels, making it hard to see what was pending.” The explanation need not defend the choice at length. One or two sentences should give a future reader enough context to avoid repeating the same discussion.
Include a link or file reference only when it helps someone act on the decision. A log entry about an approved template might point to that template; one about a naming convention might point to its instructions. Avoid copying long discussions into the log. If the background is important, link to the relevant note and summarize the outcome in your own words.
Be selective about what belongs in the log
Record decisions that other people may need to follow or that you may need to explain later. Choices about a project’s scope, workflow, responsibilities, or agreed standards are reasonable candidates. A minor adjustment that affects only one person’s next task usually does not need an entry.
A useful test is to ask whether someone joining the project next month could reasonably make a conflicting choice because they lack this information. If so, write it down. If the item is an action rather than a choice, put it in the task system instead. “Ask the team for feedback” is a task; “Use the revised draft after the team reviews it” could become a decision once the review is complete.
Keep proposed choices separate from settled ones. You can mark an entry “proposed” while a discussion is open, but change its status when the outcome is clear. Otherwise, a reader may mistake an idea for an agreement. If a decision is replaced, leave the original entry in place, mark it superseded, and point to the newer one. This preserves the project’s history without asking anyone to follow outdated guidance.
Make upkeep part of existing work
A decision log works best when updating it is a small step in a routine you already have. At the end of a meeting, ask whether any decisions were made and who will add them. After a significant choice in a message thread, the person moving the work forward can write a short entry. This is usually easier than assigning someone to reconstruct a week of conversations later.
Review the log when starting a new phase, handing work to another person, or returning to a paused project. Look for entries whose conditions have changed, choices that were never finalized, and links that no longer lead to the intended material. You do not need to rewrite the entire document; clarify only what could mislead the next reader.
The goal is not to document every turn the project takes. It is to leave a reliable trail at the points where an unexplained choice would slow someone down. Begin with the next meaningful decision, keep its entry brief, and let the format become more detailed only if the work calls for it.
