Project governance
How to Use a Decision Log to Make Leadership Meetings More Effective
A status meeting can describe every project accurately and still leave the organization unable to act. The missing ingredient is often a decision: who can approve a tradeoff, what information they need, and when the answer must be available.
This guide proposes a simple decision log for managers who need clearer execution without introducing a large project management system. It is a suggested operating practice, not a claim that one format works for every organization.
Separate decisions from actions and risks
An action is work someone has agreed to perform. A risk is an uncertain event that may affect an outcome. A decision is a choice between alternatives that requires authority. Mixing these into one undifferentiated task list makes it difficult to see which items need leadership attention.
For example, preparing a vendor comparison is an action. The possibility of a delayed installation is a risk. Selecting a vendor or changing the installation date is a decision. Track the relationship between these items, but label them clearly.
Use seven fields that make a decision actionable
- Decision needed: State the choice as a question, such as whether to reduce scope or extend the deadline.
- Decision owner: Name one person with authority to make that choice. List required approvals separately when policy requires more than one.
- Needed by: Record the date the answer is needed to protect the next milestone, not an arbitrary reminder date.
- Options: Summarize feasible alternatives and their main consequences.
- Recommendation: Identify the proposed option and explain the assumptions behind it.
- Outcome and rationale: Record the actual choice, decision date, and reasoning.
- Follow-through: Link the resulting actions to named owners and due dates.
Keep supporting documents linked rather than copying every discussion into the log. The goal is to make the choice understandable enough for the authorized person to act.
An illustrative example: choosing a system rollout approach
Consider a fictional service business introducing a shared scheduling system. One team wants a single launch date. Another needs additional training. The project manager can coordinate the work but cannot decide which operating disruption is acceptable.
The decision question might be: Should the business launch all teams together or pilot with one team first? The operations director is the decision owner. The project manager documents the alternatives, training readiness, support coverage, and dependencies. The decision is needed before training invitations are sent.
A recommendation for a pilot should explain its limits: which team participates, what success means, what would pause expansion, and who decides whether the next team is ready. If leadership chooses a single launch instead, the log should capture that rationale and any conditions, such as confirmed support coverage. The log is a record of the authorized choice, not a device for disguising the project manager's preference as approval.
Redesign the meeting around unresolved choices
Send routine progress updates before the meeting when practical. During the meeting, review decisions whose deadlines are approaching, items blocked by missing authority, and previously approved actions that need intervention.
For each decision, ask: Is the owner present? Are the options clear? What evidence is missing? Can the choice be made now? If not, assign responsibility for obtaining the missing information and set a specific return point.
Do not force a decision simply to clear the agenda. A documented delay can be appropriate when the consequences are understood and the right person accepts them. Avoid treating silence or absence as approval.
Close the loop after approval
A recorded decision does not implement itself. Tell affected teams what changed, update the relevant plan, and assign the resulting work. If a new choice reverses an earlier one, retain the previous entry and link the replacement so that readers can follow the history.
This is especially useful when decisions change a handoff between departments. Both teams need the same understanding of the new responsibilities and effective date.
Review whether the log is useful
After a short pilot, review overdue decisions, items reopened because the original question was unclear, and approved choices that never became assigned actions. Use those observations to improve the process rather than score individuals without context.
Start with one recurring leadership meeting and a shared table. If the log becomes another place to duplicate updates, remove fields or narrow its scope. A useful decision log helps people make and implement choices; its value is not the number of rows completed.
ADH Enterprises supports project execution, governance, and organizational effectiveness. Contact us to discuss where decisions are slowing your organization's work.