project decision log
Also called: project decisions log
A dated list of the project's decisions: what was decided, by whom, which options were dropped and why. When a stakeholder asks why physics launches without a mobile app, the answer is a link, not a meeting.
A decision log is a dated list of the decisions a project has made, a few lines each: what was decided, who decided, which options were dropped and why, and what the decision changes. It is the project's memory. Weeks later, when someone new joins or a stakeholder asks why the project went one way and not the other, the answer is a link instead of a meeting.
The useful fields are few. Date. Decision, in one sentence. Decided by, a named person, not "the team". Options dropped, with the reason each lost, which is the field people skip and the one that saves the most time, because dropped options tend to come back as new ideas. What it changes: dates, money, scope, who does what. Optionally, a review date if the decision is meant to be revisited with better data.
Keep out what makes a log unreadable or unsafe: the full chat history behind the decision, and a tally of who argued for what. The log records the choice and its reasoning, not a scorecard of people.
A decision log works best next to two other habits: changes arrive through one door as written requests, and the weekly status links the decisions made that week. Written, async records also make remote work easier: people in different places and on different schedules read the same answer.
Example
An entry in the decision log of Klasna's physics launch, January 2027:
6 January 2027. No free trial physics lesson before opening; revisit on 1 March with February booking data. Decided by: Leo (sponsor), in writing. Options dropped: a free trial for all 100 waiting-list families: 100 × 461 UAH (430 tutor payout + 31 video and AI) = 46,100 UAH, out of the 52,000 UAH left under the ceiling, plus 4 of Danylo's days in January. Why: it would leave 5,900 UAH of reserve and push checkout testing past its date. Changes: nothing in scope; the marketing lead's waiting-list email goes out without a trial offer.
Other entries in the same log answer questions that will come back: why physics opens without a mobile app (it was on the out list of the brief from October), and why the parent progress dashboard and the video solutions were cut (together 28 likely days and 141,000 UAH, while the 17 musts already took 131 of the 150 person-days of capacity). When someone asks again in February, the answer is a link.
Common mistakes
- Leaving out the dropped options. They come back as "new" ideas; record them with the reason they lost.
- "Decided by the team". Name the person who made the call, so the next question has an address.
- Pasting the whole chat. Nobody rereads it; write five lines a stranger can follow.
- Recording who argued for what. It turns a record into a scorecard and makes people careful about speaking up.
- Logging after the fact, from memory. Write the entry when the decision is made, with the numbers that drove it.
Learn it in the course
- Changes without a committee, and a decision log · Route every change through one door, write a short impact note in days and money, let a named person decide, and record each decision in a few lines.