A project decision register, also called a decision log, records choices that affect workflow, scope, data, or responsibility, plus the reason, owner, date, status, assumptions, and affected work.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Capture the choice
State the question, options considered, selected approach, and decision maker. Keep the entry short enough to maintain. For a routing rule, explain which team receives the work and why. Link to detailed specifications where necessary rather than copying a large document into every entry.
Record the assumptions
Identify facts that would cause the decision to be reconsidered. For example, an initial manual import may depend on a limited transfer frequency. When that frequency changes, the team can revisit the choice using evidence rather than debating whether the original decision was simply wrong.
Distinguish pending from approved
An idea discussed in a meeting is not automatically an instruction to implement it. Mark unresolved decisions and their required owner. Include the date by which an answer is needed when it affects delivery, so blocked work is visible before it becomes a surprise delay.
Use the log during change
When a feature request conflicts with an earlier choice, compare the new evidence with the recorded reason. Update the decision deliberately and identify affected work. This makes the log an operating tool for the project, not merely meeting minutes stored after everyone has already moved on.