Decision Log vs Change Log: Which One Answers "Why Did We Do That?"

On a multi-year platform program I ran, we descoped the same reporting module three times. Once in March, when the budget got trimmed. Again in June, when a new workstream lead named Dana rebuilt her plan and put it back in, and a sponsor review took it back out. A third time in October, when a different sponsor asked why reporting wasn't in the plan, someone re-added it, and we spent two more weeks arguing our way back to the same cut.

Three descoping decisions. The same decision, made three times, at a cost of roughly six weeks of combined argument. Nobody had written down why we cut it the first time, so every new person who touched the plan got to reopen it. I was the program manager. The fix would have taken two minutes in March.

That program is why I keep both a decision log and a change log now, and why I stopped letting them share a tab. They look similar. They both record things that happened. But they answer two different questions, for two different audiences, and conflating them is how you end up with one messy spreadsheet that answers neither.

The short version

• A decision log is rationale memory. It records why a choice was made at the moment it was made: the options considered, the reasoning, the owner. Its job is to kill re-litigation. It is the artifact that answers "why did we do that?"
• A change log is the audit trail. It records what moved on the program after commitments were set: scope, dates, budget, and who approved the move. Its job is to defend the program. It is the artifact that answers "how did we get here, and who signed off?"

One looks backward at reasoning. The other tracks deviation from a baseline. Most programs conflate them into one tab, and the tab does both jobs badly.

What a decision log is for

A decision log (some organizations call it a decision register) is the project management artifact that captures a choice at the moment it is made, while the reasoning is still fresh and the people who made it are still in the room. The core is five fields: date, the decision itself, options considered, rationale, and owner. Two minutes per entry. The whole record fits in a paragraph.

The value is not in the format. The value is in the timestamp. Six months after a decision, "everyone remembers it" has decayed into three conflicting recollections and one new director who wasn't there. The log entry does not decay. When someone asks in a steering meeting why you chose vendor A over vendor B, you do not reconstruct. You read.

Most decision log templates fail because they demand too much ceremony: ten fields, a sign-off workflow, an attached business case. Nobody fills those out. The strongest ones ask for five fields and get filled out the same day. A four-sentence record written in the moment survives org changes, sponsor changes, and your own forgetfulness. The version in your head does not.

Who reads a decision log

Future people. That is the honest answer. The new sponsor who inherits the program in month nine. The director who joins a steering meeting and asks the question nobody can answer. The team itself, when a settled call resurfaces and someone wants to re-open it. The decision log in project management is not a working document you review weekly; it is a reference you open at the exact moment someone challenges a call, and it ends the challenge in thirty seconds instead of a week.

You are also a reader. The version of you eight months from now, staring at a line item you cannot explain, is the single most frequent user of the log.

What a change log is for

A change log starts working the day your baseline is set. Charter signed, scope committed, dates published. From that day forward, every move against those commitments gets a row: what changed, the impact in numbers (weeks, dollars, percent of scope), the decision on it, and who approved. It is change control without the 10-page CR form, and its posture is defensive by design.

The change log is what saves you in month seven, when the launch date has slipped six weeks and a VP wants to know how. Without it, the answer is a mumbled story about a lot of small things. With it, the answer is a list: CR-04 added currency conversion (+2 weeks, sponsor approved May 12), CR-09 absorbed the compliance requirement (+3 weeks, steering approved June 30), CR-11 traded a week back by cutting the admin dashboard. The slip stops being a failure of management and becomes a sequence of approved trades.

It also catches the quieter killer: scope creep. No single change moves a program 30%. Fifteen individually reasonable changes do, and without a running log with a monthly audit against the original baseline, nobody notices until the program is delivering something no one remembers agreeing to. It is the same split I covered in RAID log vs risk register: one artifact works the program, the other defends it.

Who reads a change log

Approvers and auditors. The sponsor who signs off on the mid-tier changes. The steering committee that owns the big ones. The finance partner reconciling the budget. Occasionally an actual auditor. The change log's audience is whoever has the standing to ask "who approved this?", and the log's entire job is to make sure that question has a boring answer.

The honest comparison table

How they feed each other

The two logs are not parallel systems. They connect at a specific joint: an approved change is very often the output of a logged decision.

Walk through a real sequence. A compliance requirement lands mid-program. The team weighs three options: absorb it and slip the date, cut the admin dashboard to make room, or spend $60K on contractors to hold the date. That deliberation is a decision, and it belongs in the decision log: options named, rationale written, owner attached. The outcome (cut the dashboard, hold the date) then lands in the change log as a CR with its scope impact and its approver.

The director move is to make the change log entry point back at the decision that authorized it. One column, one cross-reference: "per D-14." Now the audit trail and the rationale memory are linked. When someone reads the change log in month ten and asks why the dashboard got cut, the row itself sends them to the reasoning.

Miss the link and you get the worst of both: a change log full of moves nobody can explain, and a decision log full of reasoning nobody can trace to what actually shipped.

When you can get away with just one

Some programs genuinely need only a decision log:

• Pre-baseline work. Discovery phases, incubation programs, anything where scope and dates are not yet committed. There is no baseline to track changes against, but there are plenty of decisions worth logging. Start the decision log at kickoff; start the change log the day the charter is signed. (If the charter itself is fuzzy, fix that first: program charter vs project charter covers what a real baseline looks like.)
• Small internal efforts where you are the approver of every change. A change log that only ever records "PM approved" is overhead. Log the decisions; skip the CR machinery.

And some can lean on the change log alone:

• Fixed-scope delivery against a contract. When the reasoning was settled in the SOW and the only live question is what moves and who pays for it, the change log carries the weight.
• Short programs, under three months. The team that made the decisions is still in the room at closeout. Rationale memory matters less when nobody has had time to forget.

Anything multi-quarter with a real baseline and real sponsor turnover needs both. That is most enterprise programs. The people change faster than the program does, and each log covers a different half of what the new people will ask.

The most common failure mode

The failure I see most often is the hybrid tab. It usually starts as a change log, because change requests force themselves on you. Then someone adds a "rationale" column, because a sponsor asked why once. Then decisions that are not changes start getting rows, because there is nowhere else to put them. Six months in, the tab has 60 rows where approved date-slips sit next to vendor selections next to a half-explained architecture call, and no row has enough fields to do its actual job.

The tell is in the questions it cannot answer. Ask the hybrid tab "why did we choose this platform?" and you get a decision row with no options and no rationale, because the columns were built for CR impact. Ask it "how much scope have we added since the baseline?" and you cannot total it, because half the rows are not changes. Two jobs, one format, zero answers.

The fix costs nothing: two tabs in the same workbook. Decisions in one, five fields. Changes in the other, five fields. A cross-reference column joins them. The formats stay honest because each tab serves exactly one question.

Practical setup for a new program

1. Day 1: open the decision log. Log the kickoff decisions the same week they happen, including the ones that feel too obvious to write down. "We chose the phased rollout over big-bang" is exactly the entry someone will challenge in month six.
2. Baseline day: open the change log. The day scope, dates, and budget are committed, the change log goes live. Set the approval tiers the same day: what the PM can approve alone, what needs the sponsor, what goes to steering. Retrofitting an approval policy during a scope fight never goes well.
3. Per decision: two minutes, five fields. Date, decision, options considered, rationale, owner. Write it within 48 hours or the options and rationale start rewriting themselves in memory.
4. Per change: one row, one number, one approver. An impact field without a number is theater. "+2 weeks" is an entry; "some schedule impact" is not.
5. Monthly: run the creep audit. Total the approved changes against the original baseline and put the number in the status report. The month that total crosses 10% is the month to walk it into the sponsor's office.

Total ongoing cost is maybe fifteen minutes a week. The reporting module I descoped three times cost six weeks. The math has never been close.

The bottom line

A decision log records why you chose. A change log records what moved and who approved. The decision log kills re-litigation; the change log defends the program. They meet where an approved change points back at the decision that authorized it.

If you are forced to start with one, start with the decision log. Changes announce themselves; someone will always chase an approval. Decisions slip away silently, and by the time you discover the rationale is gone, you are standing in a steering meeting with a quiet room and a week of reconstruction ahead of you. Almost no one writes the two-minute entry. Almost everyone wishes, eventually, that they had.