Free Decision Log Template — Excel Download

01 — What's Included

What's in the Template — 9 Columns Explained

The Decision Log is a single-sheet Excel file with a violet branded header, project metadata row and 40 pre-formatted decision entries. Each row captures the full context of a decision — not just what was decided but who decided it, what else was considered and what changes as a result.

Column	Field	What to Enter
ID	Decision Number	Pre-filled DEC-001 to DEC-040. Add more by copying the last row downward.
Date	Decision Date	The date the decision was formally made — not the date it was first discussed.
Decision Made	The Decision	State the decision in one clear sentence starting with an active verb: "Selected AWS as cloud platform" not "AWS".
Category	Drop-down	Technical / Commercial / Scope / Schedule / Resource / Risk / Other. Validated drop-down — keeps the log filterable by type.
Alternatives Considered	Other Options	List the realistic alternatives that were genuinely evaluated before this decision was made. "Azure, GCP" not just "other providers".
Rationale	Why This Choice	The specific reason this option was chosen over the alternatives. Should reference criteria: cost, risk, capability, timeline, existing relationships.
Impact	What Changes	What changes in the project as a result of this decision — scope, plan, resource, documentation that needs updating.
Decision By	Owner	The person who made or formally authorised the decision. One named individual — not "the team" or "stakeholders".
Review Date	Optional Review	If the decision may need revisiting (e.g. vendor shortlist before final award), set a review date. Leave blank for permanent decisions.

💡

The two most important columns: Alternatives Considered and Rationale are the columns that most decision logs either omit or fill in vaguely. They are also the two columns that matter most when a decision is challenged months later. Without them, the log just tells you what was decided — not why, which is the only part anyone ever disputes.

02 — Decision Categories

The 7 Decision Categories — When to Use Each

The Category drop-down in the template uses seven standard categories. Consistent categorisation lets you filter the log by type — useful when you need to find all technical decisions for a design review or all commercial decisions for a contract audit.

⚙️

Technical

Architecture, technology stack, tools, build vs buy, coding standards

💼

Commercial

Vendor selection, contract terms, pricing model, procurement approach

🎯

Scope

What's in and out, feature prioritisation, requirements interpretation

📅

Schedule

Milestone dates, phasing, sequencing, dependency resolution

👥

Resource

Team structure, role assignments, outsourcing, training decisions

⚠️

Risk

Risk response strategies, accepted risks, escalation thresholds

📋

Other

Governance, reporting, communication, anything that doesn't fit above

🔽

Drop-down

All 7 are validated in-cell — no free text needed

03 — What to Log

What Goes in the Log — and What Doesn't

The most common mistake with a decision log is either logging everything (making it unwieldy) or logging too little (making it useless). The filter is simple: would forgetting the rationale for this decision cause problems later? If yes, log it.

Always Log These

Any decision that is difficult or costly to reverse. Any decision that affects more than one team member or work stream. Any decision that changes a project baseline or assumption. Any decision involving vendor selection, technology choice or architecture. Any decision where two or more stakeholders had competing preferences.

Don't Bother Logging These

Day-to-day operational choices with no lasting project impact. Decisions already documented in other formal project documents (e.g. an approved change request already records the decision and rationale). Routine administrative decisions like meeting scheduling or document naming conventions.

Writing a Decision Entry That Holds Up

❌ Weak entry

"Decided to use PostgreSQL. Agreed with team. Good for project."

No alternatives listed. No rationale. "Good for project" is not a reason. Useless in 6 months when someone asks why not MySQL.

✅ Strong entry

"Selected PostgreSQL as the primary database. Alternatives: MySQL, MongoDB. Rationale: existing team expertise in PostgreSQL, superior support for complex joins required by reporting module, open-source licence reduces cost vs Oracle. Decision by: Lead Architect (J. Ahmed), 14 March."

Specific decision, named alternatives, concrete rationale tied to project requirements, single named owner with date. Holds up to challenge.

📌

Update the log in real time, not retrospectively. Decision logs written retrospectively at project end — often as a compliance exercise — are almost always incomplete and inaccurate. The rationale is forgotten, alternatives are misremembered and dates are estimated. Update the log within 24 hours of a decision being made, ideally immediately after the meeting where it was agreed.

04 — Related Registers

Decision Log vs Action Log vs Issue Log

These three registers are often confused or collapsed into a single document. They record different things and serve different purposes. Keeping them separate makes each one more useful.

🧭

Decision Log

Records: Choices Made

Past-tense. What was decided, by whom, why and what alternatives were rejected. Permanent record — entries are never deleted.

✅

Action Item Tracker

Records: Tasks to Do

Future-tense. What needs to be done, by whom and by when. Entries close when the task is complete and verified.

⚠️

Issue Log

Records: Problems

Present-tense problems that have occurred and need resolution. May require escalation, a change request or a formal decision — which then gets logged in the decision log.

A useful workflow: an issue is raised in the issue log → the PM and CCB decide how to resolve it → the resolution decision is logged in the decision log → any resulting tasks are added to the action item tracker. All three registers are active simultaneously throughout project execution.

05 — FAQ

Decision Log — 4 Common Questions

A decision log (also called a decision register) records all significant decisions made on a project — the date, who made the decision, what alternatives were considered, the rationale and the expected impact. It creates an audit trail that resolves disputes, helps onboard new team members and informs future projects. In PMBOK, the decision log is listed as a project document updated throughout execution and monitoring and control.

Each entry should capture: a unique decision ID; the date decided; the decision itself stated clearly and specifically; the category; alternatives that were seriously considered; the rationale explaining why this option was chosen; the business impact; the decision owner (one named person); and a review date if the decision may need revisiting. The rationale and alternatives columns are the most important — without them, the log just tells you what was decided, not why.

A decision log records choices that have been made — past-tense outcomes with rationale and impact. An action item tracker records tasks that need to be done — future-tense commitments with owners and due dates. Decisions often generate action items (a decision to change the technology stack generates actions to update architecture documents, retrain the team, procure new licences), but they are different record types. Keeping them separate makes each register cleaner and more useful.

Log any decision that would be difficult or costly to reverse, affects more than one team member, changes a baseline or assumption, or where the rationale would be hard to reconstruct later. This typically includes: vendor and technology selection, architecture choices, scope inclusions and exclusions, team structure decisions, budget allocation choices and risk response strategies. Day-to-day operational decisions with no lasting impact (meeting room booking, document formatting) do not need to be logged.

Free Decision Log Template Excel Download