Why decisions need their own record
A project can have a clear task list and still lose track of important choices. A client may approve one approach during a call, request a different one by email, and later ask why the original plan changed. A decision log gives everyone a short, shared record of the choice that governs the work. It does not replace the scope, schedule, or meeting notes; it connects those documents to the decisions made along the way.
A useful log answers four questions: what was decided, who agreed to it, when it was agreed, and what the decision changes. Recording the reason can also help when someone revisits the choice weeks later. The goal is not to document every conversation. Focus on decisions that affect deliverables, priorities, cost, timing, or who must do the next piece of work.
Set up a log people can actually use
A shared table or document is usually enough for a small project. Give each entry a short title and a consistent set of fields: decision, date, decision-maker, reason, affected work, and follow-up owner. Add a status such as proposed, confirmed, or superseded if choices often remain open after meetings. Keep the language specific enough that a teammate who missed the conversation can understand what to do.
For example, “Use the shorter review process” leaves too much open. A clearer entry might say: “The client will provide one consolidated round of comments on the first draft; the project lead will collect them by the agreed review date.” If the review date has not been settled, mark it as an open follow-up rather than filling in an assumed deadline. Link or refer to the relevant task in your own project workspace so the record is easy to act on.
Decide where the log lives at the start of the project and make one person responsible for maintaining it. Others should still be able to suggest corrections. A log hidden in one person’s private notes may be accurate, but it will not help the team coordinate.
Separate a proposal from a confirmed decision
Many misunderstandings begin when a suggestion is treated as approval. During a meeting, note proposed choices separately from confirmed ones. Before marking an entry confirmed, check that the right person has agreed and that any conditions are recorded. If someone says, “That approach works if the product descriptions are ready,” the condition belongs in the log.
After a call, send a brief recap of consequential decisions and unresolved questions through the communication channel the project already uses. Make corrections easy: state what you believe was agreed and invite the client or team to flag anything inaccurate. This is especially useful when a decision changes the work expected from someone who was not on the call. A written recap is not a substitute for a required approval process, but it can prevent an informal conversation from becoming an ambiguous instruction.
Practice with a category-page project
Imagine a small team planning category pages for an apparel client. One decision might be whether footwear and accessories belong together or need separate pages. To develop questions for that discussion, browse Shoes and Accessories · A Stylish Man as an example of a shoes-and-accessories category label. The log should record the client’s actual choice, not treat another site’s arrangement as the answer.
A second decision could concern how to group pages around occasions rather than product types. For another category-label example to browse while preparing options, see Outfits and Occasions · A Stylish Man. Record who will choose the grouping and whether that choice changes the page outline or writing assignments.
The team might also need to decide whether clothing-care guidance belongs within product pages or in a separate content area. Browse Fabrics and Clothing Care · A Stylish Man for an example of a fabrics-and-clothing-care category label, then document the project-specific decision. In each case, browsing helps frame possible questions; the decision log preserves the answer agreed for this project.
Keep the log current as the project changes
Review open decisions during regular project check-ins. An entry marked proposed should have an owner and a next step, such as obtaining client approval or testing an option. If a decision is holding up work, make that visible in the status update rather than leaving teammates to discover it when a task comes due.
When a choice changes, do not quietly overwrite the old entry. Mark it superseded, record the new decision, and note which tasks or deliverables need updating. That history helps explain why the plan changed without requiring anyone to reconstruct a chain of messages. At project close, the log can also show which choices caused repeated questions, giving the team a practical starting point for improving its next kickoff or review process.
