How to Use a Decision Log on Consulting Projects

Projects rarely stall because nobody had a meeting. They stall because a decision was discussed, then forgotten, interpreted differently, or left without an owner.

A decision log solves that problem with a small, shared record. It is not a meeting transcript. It is a list of the choices that change the work and the actions that follow them.

Record decisions while they are fresh

Update the log during or immediately after the meeting where the choice is made. Waiting until the end of the week turns clear decisions into reconstruction work.

Each entry needs only six fields:

For example: “The client will launch the pilot with the enterprise segment first. Maya owns the audience list by September 12. This reduces launch risk but moves the broader rollout to October.” That is far more useful than “Discussed launch plan.”

Separate decisions from open questions

An open question is not a decision. Mixing them together creates false certainty.

Keep a separate list for questions that still need an answer, along with the person who will answer and the date you need it. When the answer is agreed, convert it into a decision-log entry.

This distinction makes status updates clearer. You can say: “Three decisions were made this week; two inputs remain open.” Clients know exactly what is settled and where their attention is needed.

Write the decision, not the discussion

Long meeting notes are hard to scan and easy to ignore. A decision log should let someone understand the current direction in a few minutes.

Use direct language:

• “Approve the three-phase rollout.”
• “Remove the reporting workstream from the current scope.”
• “Use the operations team’s existing intake form.”

Avoid soft summaries such as “The group leaned toward” unless no final decision was made. If the group did not decide, list the question as open and name the next step.

Confirm material decisions with the client

After a decision that affects scope, timeline, budget, or a major assumption, include it in your client update. Ask the accountable stakeholder to correct the record quickly if needed.

This is not unnecessary paperwork. It protects both sides from a common project failure: two people leaving the same meeting with different understandings of what happens next.

A short confirmation can be enough:

“To confirm today’s decision: we will prioritize the renewal workflow and defer the onboarding redesign. This changes the September milestone to a renewal pilot. Please reply by Thursday if this does not reflect the agreed direction.”

Review the log at every milestone

Before a milestone review, scan the log for decisions with uncompleted follow-up actions, expired assumptions, or impacts that have not appeared in the project plan.

Ask three questions:

1. Which decisions still need action?

2. Which assumptions have changed since we made this choice?

3. Which new decision is now blocking progress?

The log becomes especially valuable when stakeholders change, a project pauses, or someone asks why a particular path was chosen. Instead of relying on memory, you have a concise account of the project’s direction.

Keep it lightweight enough to use

Use a shared document, a project workspace, or a simple table in your delivery plan. The tool is less important than the habit.

If the log takes more than a few minutes to update, simplify it. A small record that stays current is more valuable than a detailed system everyone abandons after kickoff.

Related: How to Run a Consulting Project Retrospective Clients Actually Value | Build a Consulting Benefits Realization Plan