How to write a project decision log you can actually use.

1. Record a real choice, not every conversation.

Start with a question that could lead to different actions: should we publish a dated resource list now, or delay until a live availability system is ready? A useful record has a boundary. Name the project, the person or group served, the version or reporting window involved, and what the decision does not cover. A title such as improve the experience is too broad to help a later reader understand what was agreed.

Distinguish a decision from a task, a risk, and a meeting note. A task says who will update the page. A risk says the information may become stale. A meeting note preserves the discussion. The decision says which operating approach the team accepts and why. You can link those documents rather than copying everything into one log. Record consequential choices and avoid turning routine edits into an approval ceremony.

2. Put evidence and realistic alternatives beside the question.

Describe what is known, what is reported, and what is still an assumption. Point to a dated source note, observation, dependency check, or test result. Do not call an informal preference a demonstrated need. If somebody reports a maintenance constraint, identify which responsibility was checked and which part remains unresolved. Keep private participant records outside a public decision log; a restricted source pointer may be enough for an internal reviewer.

List the alternatives you genuinely considered, including waiting, simplifying the promise, or stopping this part of the work. Give each option a fair description and its important costs. Do not invent a deliberately unworkable alternative to make your preferred choice look inevitable. A simple comparison can ask what each option lets a person do, what has to be maintained, what uncertainty remains, and what would be hard to reverse. Unknown information should remain unknown, not become a zero in a scoring table.

3. Write the choice, the trade-off, and who can act on it.

AWS describes architectural decision records around context, a decision, and consequences, with later records superseding earlier accepted choices. That reference concerns software architecture. The worksheet here adapts the general idea of preserving rationale to a broader small-project decision; it is not an AWS process or an architectural approval record. You do not need to adopt an elaborate lifecycle to make your own reasoning inspectable.

Write one direct sentence stating what will happen, followed by why the available evidence favours it over the alternatives. Name the drawback you are accepting and the claim you are not making. Assign a person or role responsible for the next action, and distinguish that owner from whoever has authority to approve the commitment. If approval has not happened, keep the status proposed. Recording a choice does not give a team member permission to spend money, publish private material, or make a promise on somebody else's behalf.

4. Decide what would make you reconsider.

A review date is useful, but a date alone does not explain what you need to learn. Add a trigger connected to the reason for the choice. For a resource list, a trigger might be that nobody can maintain the agreed update schedule, that observed visitors repeatedly misunderstand availability, or that a delivery partner changes the conditions. State who will check and what action follows if the trigger occurs. Do not invent a numerical threshold simply to make the document appear scientific.

Separate the review trigger from a success claim. A team might agree to review instructions after the next observation round without claiming that a particular completion count proves demand. GOV.UK's discovery guidance treats understanding the problem and constraints as part of deciding whether further work is worthwhile. In your own project, new information may justify another test, a smaller commitment, or stopping. The log should allow those outcomes rather than being written only to defend continuation.

5. Inspect a worked example without upgrading the evidence.

Here is a hypothetical example. A small team is preparing a workshop resource page. In a limited prototype session, two participants ask whether the listed sessions are still available. A coordinator confirms that they can check a short list each week but cannot promise live inventory. These are invented observations and operating conditions, not evidence about all visitors or any real SIX33 service.

Decision D-007 is proposed: publish a short, dated list with a clear confirmation step instead of describing availability as live. The alternatives are a real-time system, a dated list, or delaying publication. The rationale is that the dated approach can fit the stated maintenance capacity while making the uncertainty visible. The accepted drawback is that a visitor may still need to confirm a place; the team must not advertise immediate booking. The owner checks the text and maintenance arrangement before requesting approval to publish.

The review trigger is a missed agreed update or a later observed misunderstanding of what confirmation means. The next action is to test whether a new participant can explain the list's date and the confirmation step without being coached. This does not prove that the resource improves attendance, that the approach is accessible to everyone, or that a booking system will never be needed. The record connects a limited observation to a limited choice and leaves room for the result to challenge it.

6. Preserve the history and close the loop.

Give the record a stable ID and keep a small index with its title, date, status, and owner. Choose a storage location your collaborators can actually find. When an important accepted decision changes, create a linked follow-up explaining the new evidence and mark the earlier record superseded. Correct an ordinary typo if needed, but do not quietly replace the old rationale with knowledge acquired afterward. The history matters because a reasonable choice under earlier conditions can become unsuitable later.

At review, record what was observed, what remains unknown, and whether the action was completed. A decision to test is not evidence that the test succeeded; an accepted plan is not a delivered outcome. If the record will inform a public update, write a separate shareable summary and remove private details, unsupported attribution, and information you lack permission to disclose. Put the finding, method, limitations, and next decision in the report. The log's job is to help the next person understand the reasoning, not to make uncertainty disappear.