Decision Log

A project team chooses a supplier after comparing cost, support and data access, and six months later a new colleague asks why the cheaper option was not selected. A decision log can answer without restarting the whole debate.

Decide which choices belong, recording decisions that affect scope, cost, risk, customers or future work, because a log filled with tiny daily preferences becomes difficult to use. Write the decision first, stating what will happen and not simply that a topic was discussed, since an entry reading "vendor options reviewed" is not a decision.

Name the decision-maker or approving group, because attendees at a meeting are not automatically authorised to approve, and add the date and status, as proposed, approved, superseded and reversed are distinct and a draft choice should not be copied into a plan as final. Capture the reason briefly, listing the main rejected alternative with evidence or links when available, since a useful explanation can be two sentences and not a full meeting transcript.

An architecture decision record community template uses context, decision and consequences, which is a useful pattern beyond software, though a general business log may need different fields. Monday.com's decision-log guide describes recording choices and owners to support project tracking, as a workflow example and not a mandatory format.

Record consequences too, since a supplier choice may require training or create a renewal risk, and assign follow-up tasks separately so the log does not pretend recording is execution. Keep links to evidence, because quotes, test results or legal advice may sit in controlled systems and should be linked appropriately rather than copied into an open table.

Choose one owner for upkeep, such as a project manager, operations lead or designated secretary, while everyone can still suggest corrections. Publish at the right scope, as team decisions should be findable by affected people while confidential personnel or commercial choices need restricted access, and use consistent identifiers such as a short ID, date and topic as a navigation aid and not a substitute for content.

When a decision changes, update rather than silently overwrite, preserving the old version and recording what superseded it, otherwise past actions appear irrational because their original basis disappears. Set review triggers, since a decision can be valid until a price changes, a pilot fails or a new rule applies, and recording the trigger prevents a temporary choice from becoming permanent by neglect.

Separate fact from assumption by labelling the assumption and the evidence available then, and avoid retrospective invention by stating what is known and leaving uncertainty visible rather than writing a polished false history. Connect decisions to actions, because a choice to change pricing needs an owner, deadline and implementation channel, and the log preserves the rationale while a work tracker manages delivery.

An illustrative completion rate is important decisions documented divided by important decisions identified in a period, so if 18 of 20 are logged that is 90%, though it does not prove the decisions were good. Review the log at milestones, because revisiting a choice with evidence is healthy and not a failure of decisiveness, avoid using it to evade accountability by omitting names, and remember that for owners it preserves why a consequential path was chosen while making it easier to revise a choice honestly when conditions change.