What is a decision log in a project?

A decision log is the running record of the significant choices a project makes — what was decided, when, by whom, why, and what alternatives were rejected. It exists because finance-system projects make hundreds of consequential decisions (a posting design, a scope call, a data rule) and, without a record, the reasons evaporate. Three months later someone asks 'why does it work this way?' and nobody remembers — so the decision gets relitigated, or worse, quietly reversed by someone who didn't know it was deliberate. The log turns decisions from tribal memory into traceable record: the answer to 'why' is a lookup, not an argument.

What is change control on a project?

Change control is the discipline of making changes to agreed scope, design or plan deliberate rather than accidental. Once something is baselined — scope, a design decision, a requirement — a change to it goes through a defined path: raised, assessed for impact (cost, time, risk, other decisions), decided by someone with authority, and recorded. The point isn't to prevent change; projects must change. The point is that every change is a conscious, owned decision with its impact understood — not a quiet tweak that unravels three other things nobody re-checked. Change control is what stops 'small' changes accumulating into a project that no longer matches what was agreed.

What is the difference between a decision log and a change request?

A decision log records decisions as they're made throughout the project; a change request is the mechanism for altering something already agreed. They're linked: a change request, once decided, becomes an entry in the decision log. Think of the decision log as the full history of what was chosen and why, and change control as the gate that governs changes to previously-agreed items. A project needs both — the log so choices are traceable, and change control so changes to baselined work are deliberate and impact-assessed rather than silent.

Decision Log & Change Control for Finance Systems

Two things quietly sink finance-system projects: decisions nobody recorded, and changes nobody controlled. Not dramatic failures — slow ones. A posting design agreed in week six, questioned in week twenty by someone who wasn't there, relitigated for a day because no one can say why it was chosen. A "small" scope tweak slipped in during UAT that unravels three earlier decisions nobody re-checked. Individually trivial; collectively, they're how a project drifts from what was agreed into something no one quite decided. A decision log and change control are the unglamorous disciplines that prevent both — and they're the first things dropped when a project gets busy, which is exactly when they matter most.

Decisions are the project's real output

A finance-system project produces a working system, but along the way it produces something just as valuable and far more perishable: decisions. How each deal type posts. Which system owns which data. What's in scope and what's explicitly out. Every one is a choice with a reason, and the reason is the part that evaporates.

The failure is predictable: three months on, someone asks "why does it work this way?" — and the answer lives only in the memory of whoever's since rolled off the project. So the decision gets relitigated (expensive) or quietly reversed by someone who didn't know it was deliberate (dangerous). A decision log fixes this by making the reason a record, not a memory.

The decision log: what each entry needs

A decision log is only useful if each entry captures enough to answer "why" without the person who decided it. The fields that earn their place:

Field	Why it matters
Decision	What was actually decided, in one clear sentence
Date	When — so you can tie it to the state of the project then
Owner / decider	Who made it — accountability, and who to ask
Context / why	The reason and the constraints at the time
Alternatives rejected	What was considered and not chosen, and why
Impact / affects	What else depends on this decision

The field everyone skips is alternatives rejected — and it's the one that stops relitigation. "We chose A" invites "but what about B?"; "We chose A over B because B couldn't handle multi-currency" ends the conversation. Recording the rejected option records the thinking, which is the whole point.

The decision log's job is to make "why does it work this way?" a lookup instead of an argument. A project that can't answer that question is one bad week from reversing a decision it made for good reasons it forgot.

Change control: make change deliberate, not accidental

Change control is the twin discipline. Once something is baselined — scope, a design decision, a requirement — changing it should be a conscious, owned act, not a quiet tweak. The path is simple and non-negotiable:

Raise. The proposed change is written down — what and why.
Assess impact. Cost, time, risk, and which other decisions it touches — the step that catches the "small change" that isn't.
Decide. Someone with authority approves or rejects it, deliberately.
Record. The outcome becomes a decision-log entry, so the change is now part of the traceable history.

The purpose isn't to resist change — finance-system projects must change as they learn. It's to make sure no change is silent. The most damaging changes aren't the big ones everyone debates; they're the "obvious" small ones slipped in without impact assessment, each unravelling something nobody re-checked.

The two connect: a change becomes a decision

Decision log and change control aren't separate systems — they're one traceable history with a gate. Everyday design decisions go straight into the log. Changes to already-baselined items go through change control first, and then the outcome lands in the log. Together they answer the two questions that stall projects and audits:

"Why is it like this?" → the decision log.
"Who approved changing it, and did they understand the impact?" → change control.

This is the delivery-side twin of environment config promotion: there, you control how config moves; here, you control how decisions and scope move. Same principle — deliberate change over convenient change — applied to the choices instead of the system.

What usually goes wrong

Decisions in chat. The real decision log is a scattered trail of messages and meeting notes nobody can search, so "why" is unanswerable.
No rejected-alternatives. Only the chosen option recorded, so every past decision is re-openable by anyone who wasn't there.
Silent scope creep. "Small" changes made directly, without impact assessment, until the system no longer matches what was signed off.
Change control as bureaucracy. A heavy process nobody uses, so change routes around it entirely — worse than no process, because it's ignored and resented.
Dropped when busy. Both disciplines abandoned exactly when the project is moving fast and making the most decisions — the worst possible time to stop recording them.

What I would decide

Keep both lightweight enough to actually use. A decision log is a single searchable table with the fields above — not a document management system; the moment it's heavier than the decisions it records, it stops being used. Change control is one gate — raise, assess impact, decide, record — applied only to baselined items, so it governs the changes that matter without slowing the everyday ones. And treat "alternatives rejected" and "impact assessed" as the two non-negotiable fields, because they're what turn a log from a list into a defence and a change from a tweak into a decision. Projects don't fail because they made bad decisions; they fail because they forgot the good ones and changed them by accident.

Part of the Finance Systems Delivery guide. See also the RAID log and governance and steering for finance programmes. The newsletter sends one finance-systems pattern, product decision or build lesson every two weeks.