Stop Reopening Old Decisions: Build a Decision Log Your Team Will Actually Use

A lightweight decision log preserves the outcome, reason, owner and review trigger so teams can move forward without repeating the same discussion.

You leave a meeting with a clear decision. Two weeks later, the same topic appears again in another meeting. Someone missed the context. Someone else remembers a different version. A new stakeholder asks why the option was rejected. Suddenly the team is not progressing the work. It is reopening the past.

This is one of the quiet ways projects lose time.

Most teams do not suffer from a lack of decisions. They suffer from decisions that disappear into meeting notes, emails, chat threads, slide decks and people’s memory. When that happens, every change in stakeholder, priority or pressure creates an opportunity to relitigate something that was already resolved.

A decision log is a simple way to stop that drift. Not a bureaucracy. Not a governance artefact for its own sake. A lightweight record of what was decided, why it was decided, who owns it and when it should be reviewed.

Why Lost Decisions Create Real Work

Reopening old decisions feels harmless because it often starts as a reasonable question: “Why did we choose this?”

The problem is not the question. The problem is when the team has no shared record of the answer.

Without a decision log:

• new team members rely on second-hand explanations
• stakeholders challenge decisions without seeing the original trade-offs
• project managers waste time reconstructing history
• teams confuse a changed context with a forgotten decision
• accountability becomes blurred because ownership was never recorded

The result is rework dressed up as alignment.

Decision records are more than meeting administration. UK and Australian government guidance both emphasise preserving useful context and managing business information for sound decisions, accountability and risk control.

That principle applies just as strongly inside ordinary project teams.

What a Decision Log Is, and What It Is Not

A decision log is not a replacement for judgement. It will not make hard choices easy. It will not remove politics, ambiguity or competing priorities.

What it does is preserve the shape of a decision so the team does not need to rediscover it later.

The simplest decision log has seven fields:

• Decision: What was agreed?
• Date: When was it agreed?
• Owner: Who is accountable for the decision?
• Context: What problem or constraint drove the decision?
• Options considered: What alternatives were rejected?
• Impact: What changes because of this decision?
• Review trigger: What would justify reopening it?

That last field matters. A good decision log does not freeze decisions forever. It clarifies the conditions under which a decision should be revisited.

How to Build a Decision Log That Stays Useful

1. Start With Decisions, Not Documents

Do not begin by designing the perfect template. Begin by noticing where decisions are already being made.

Look at recent meetings, steering committee packs, sprint reviews, workshops or working group notes. Ask:

• Which choices changed the direction of the work?
• Which approvals unlocked the next step?
• Which trade-offs affected scope, time, cost, quality or risk?
• Which assumptions would create trouble if forgotten?

Those are the decisions worth logging.

The test is simple: if someone asked in three months, “Why did we do this?”, would the answer matter?

2. Name One Decision Owner

Many decisions involve several voices, but the log should show one accountable owner.

Consultation can be broad, but approval should be clear. Atlassian’s DACI framework separates the person driving a decision, the approver, contributors and people to inform. Its core lesson is simple: distinguish coordination from authority.

When ownership is unclear, decisions drift. People keep debating because nobody can tell whether the matter was actually closed.

The owner field does not need to create a hierarchy. It creates clarity.

3. Capture the Reason, Not Just the Outcome

“Approved option B” is not enough.

The value of a decision log is in the reasoning. A future reader needs to know why option B made sense at the time. Was it cheaper? Faster? Safer? Easier to support? Better aligned to a policy, strategy or customer need?

A useful entry might say:

Decision: Use the existing case management platform for the pilot rather than procuring a new tool.

Reason: The pilot needs to start within six weeks, the current platform meets minimum workflow needs, and procurement would introduce schedule risk. This decision can be reviewed if pilot volume exceeds 500 cases per month or integration constraints block reporting.

That kind of record saves hours later because it preserves the constraint set.

4. Record the Options That Were Rejected

Teams often forget what they already considered. This is why old options return as new ideas.

A short rejected-options field prevents circular debate. It does not need to be defensive. It just needs to be specific.

For example:

• new platform rejected because of procurement lead time
• manual workaround rejected because quality risk was too high
• deferment rejected because regulatory date was fixed

This helps new stakeholders understand that the team did not ignore alternatives. It made a trade-off.

5. Link Decisions to Actions

A decision that does not change anything is usually just a discussion.

Every important decision should connect to a next action, owner or change in plan. If the team decides to reduce scope, update the plan. If it approves a process change, update the process owner. If it accepts a risk, update the risk register.

This is where decision logs become practical rather than archival. They help the project manager track whether the decision actually moved into delivery.

6. Keep the Format Boring

A decision log should be easy to update in less than two minutes.

Use a table, spreadsheet, project wiki page or lightweight database. Avoid anything that requires special formatting or a monthly clean-up ritual. The more polished the artefact needs to be, the less likely people are to maintain it.

Good decision logs are usually boring:

• one row per decision
• plain language
• short notes
• clear owner
• links to source material where needed

Boring is good. Boring gets used.

7. Review It for Five Minutes Each Week

A decision log is only useful if it stays visible.

At your next weekly meeting, review three questions:

• Were any decisions made this week that should be logged?
• Have any review triggers been reached?
• Are there decisions in progress that need an owner or deadline?

This takes five minutes. It also prevents weeks of drift.

Then place the link somewhere visible: the project homepage, team channel, status report or governance pack. If people have to hunt for the log, they will stop using it.

A Practical Decision Log Template

You can start with this structure:

Field	Prompt
Decision	What was agreed in one sentence?
Date	When was it agreed?
Owner	Who is accountable for the decision?
Context	What problem, constraint or opportunity led to the decision?
Options considered	What alternatives were considered and rejected?
Impact	What changes in scope, time, cost, quality, risk or work practices?
Review trigger	What would justify reopening the decision?
Related link	Where is the source material, meeting note, paper or approval?

Do not wait for the perfect system. Start with the next real decision your team makes.

Common Mistakes to Avoid

The first mistake is logging too much. Not every comment, preference or minor action needs to become a decision record. Focus on choices that affect delivery, governance, risk, stakeholders or future work.

The second mistake is writing entries that are too vague. “Proceed with option B” will not help later unless the reason is clear.

The third mistake is treating the log as the project manager’s private notebook. A decision log should be visible to the people affected by the decisions.

The fourth mistake is never reviewing it. A decision log that is updated once and forgotten becomes another abandoned artefact.

The fifth mistake is reopening decisions without a trigger. If the context has changed, revisit the decision. If the context has not changed, use the log to keep moving.

Make It Useful on Monday Morning

Here is the smallest useful version:

1. Create a shared table with the seven fields.
2. Add the last three important decisions your team made.
3. Record the reason each decision was made.
4. Add a review trigger for each one.
5. Link the table from your next meeting agenda or status report.

That is enough to start.

The aim is not to document everything. The aim is to protect the team from losing the same decision twice.

When decisions are visible, teams move faster. Not because they avoid debate, but because they know which debates are still open, which ones are closed and what would need to change before reopening them.

That is practical governance. It is also a quieter, better way to work.

Connect with Raf on LinkedIn or follow rafsanga.com for more ideas on practical delivery, process improvement and technology-enabled change.

Sources and Further Reading

• Atlassian Team Playbook: DACI Decision-Making Framework
• UK Government Digital Service: Documenting architecture decisions
• National Archives of Australia: Information Management Standard for Australian Government
• National Archives of Australia: Integrity and Information Management guidance
• Atlassian Team Playbook: Decision-Making Retro