The Project Decision Log Your Successor Can Read

The instinct right after a hard decision is to move on to the next problem. That instinct is exactly backward. The few minutes right after a decision gets made are the only time anyone will ever agree, without an argument, on what was decided and why, because that's the last moment everyone in the room remembers it the same way.

The direct answer: a project decision log is a short, running record of the decisions that shape a plan, what was decided, who decided it, the date, the options that were rejected, and why, written down while everyone still agrees on it. Without one, the same decision gets re-argued weeks later, because two people remember agreeing to different things and nothing on paper settles it.

What a Project Decision Log Actually Records

Every project produces a string of decisions nobody quite remembers making the same way twice: which vendor got picked and why the runner-up lost, whether the scope cut was the sponsor's call or the PM's, why the architecture went one direction over another that looked just as reasonable at the time. A decision log pulls those calls out of the meeting where they happened and writes them somewhere they can be found again, distinct from an assumption log, which tracks what the plan is betting on rather than what's already been decided. A decision is settled; an assumption is still open. Collapsing the two into one tracker loses the distinction that makes each useful on its own.

The Minimum Viable Decision Log Format

A decision log entry needs exactly five fields, and anything beyond that mostly adds upkeep nobody sustains:

1. The decision, stated as a specific, checkable outcome, not "we discussed vendors" but "we selected Vendor B for the integration."
2. The date, so the entry can be placed against the schedule and against whatever changed afterward.
3. Who decided it, the actual accountable person, sponsor, technical lead, steering committee, not the PM by default just because the PM wrote the entry.
4. The options that were rejected, briefly, because the alternative nobody chose is exactly what gets re-proposed six months later by someone who wasn't in the room.
5. The reason, one or two sentences on why this option won, written for someone with none of today's context.

The diagram below shows what those five fields look like as a single entry.

Where Decisions Go to Die Without One

Most projects already "record" decisions somewhere. The problem is that none of the usual places are built to be found again.

	Meeting notes	Chat thread	Decision log
Findable months later	Buried in a shared drive, rarely reopened	Searchable, but drowned in unrelated messages	One row, one place, by decision
Shows who decided	Sometimes, if someone happened to be named	Whoever typed last, not necessarily who decided	A named, accountable owner, always
Shows what was rejected	Rarely captured at all	Rarely, and buried in the scroll	A required field on every entry
Survives a tool switch	Copied by hand or lost	Lost when the channel archives	Exported with the rest of the project
Settles a dispute later	Weak; the notes themselves get disputed	Weak; easy to quote a message out of context	Strong; one written version, one owner
Has a review trigger	None	None	Checked at each milestone that depends on it

What's Worth Logging, and What Isn't

Not every choice made in a meeting deserves an entry, and a log that tries to capture all of them turns into a junk drawer nobody reads. The filter is simple: log a decision if re-arguing it later would cost real time, a scope tradeoff, a vendor selection, an architecture choice, anything a sponsor formally signed off on. Skip the routine sequencing and task-assignment calls a PM makes dozens of times a week; if forgetting one wouldn't cost anyone an afternoon, it isn't a decision-log decision. That same discipline, writing down only what would actually be expensive to lose, is what keeps steering committee sessions focused on deciding rather than updating: a decision log is where the outcome of that kind of session should land immediately afterward, not a week later from memory.

Where the Payoff Shows Up: Handover and Disputes

The log pays for itself in exactly two moments, and both are expensive to handle without it. The first is handover: a successor reading the schedule can see what it says, but only the decision log tells them why it says that, which architecture got picked and what it was picked over. The PM handover checklist treats the decision log as one of the artifacts a departing PM is responsible for leaving behind, not an optional nicety. The second is a dispute, two stakeholders who remember agreeing to different things, and a written entry with a name and a date attached settles it faster than either person's memory will.

A decision log is also one of the concrete habits scored in Onplana's free PMO Maturity Assessment, alongside assumption tracking and the rest of a PMO's governance practice, rather than something a team simply assumes it's doing well. The rest of the Onplana blog covers the other artifacts, from lessons learned that people actually read to the wider handover process, that make a project's history usable to the person who inherits it.

Run the free PMO Maturity Assessment Get a clear read on where your team's planning and governance discipline, including decision and assumption tracking, actually stands today. About ten minutes, no signup required. → Open the PMO Maturity Assessment