Keep a Consulting Project Open Questions Log

Consulting projects often slow down before anyone can point to a single problem.

The team has not made a bad decision. A deadline has not officially moved. But unanswered questions are accumulating in meeting notes, chat threads, and individual inboxes. Each one delays a small part of the work until the delays begin to affect the milestone.

A consulting project open questions log makes that uncertainty visible. It records what needs an answer, who will find it, when the answer is needed, and which work depends on it. The log is simple enough to update after every client conversation and specific enough to keep unanswered questions from becoming hidden blockers.

Separate questions from decisions and actions

An open question is something the team does not know yet. It is not the same as a decision or an action item.

• Question: Which customer segments must the analysis separate?
• Decision: The analysis will use three segments: enterprise, mid-market, and small business.
• Action: Morgan sends revenue data for the three approved segments by September 16.

Keeping those records separate protects the project from false certainty. A question stays open until there is an evidence-backed answer. Once the client chooses a direction, move the result into the project decision log. If someone must complete work, add it to the action item tracker.

Give every question a reason

Do not record a vague question without showing why it matters. “What about Europe?” gives the owner too little context and makes prioritization difficult.

Write the question so another person can understand the answer you need and the work it will unlock:

Do European privacy requirements change which customer-level fields we can include in the pilot dataset? We need the answer before data preparation begins on September 18.

That version identifies the topic, the consequence, and the deadline. It also helps the client route the question to the right expert instead of guessing what the consultant meant.

Use a small set of fields

An open questions log should be easier to maintain than the uncertainty it tracks. Start with seven fields:

One owner does not mean one person must know everything. The owner is responsible for finding the right source, confirming the answer, and closing the loop.

Set deadlines from the work they affect

An open question rarely needs an answer “as soon as possible.” It needs an answer before a particular decision or task can proceed.

Work backward from that dependency. If the team needs two days to revise a model before Friday's steering meeting, the underlying data question cannot remain open until Thursday afternoon. Record the answer deadline and the affected milestone together.

When the timing is tight, make the tradeoff explicit:

We need the approved baseline by Tuesday to include it in Friday's recommendation. If it is not available, we can move the review or present the recommendation without the baseline comparison.

This turns a reminder into a useful client choice. It also keeps the consultant from silently absorbing schedule risk.

Review questions by impact

A long list can hide the few questions that matter most. Before each status update, sort open items by what they could change.

Review these first:

1. questions blocking work scheduled this week

2. questions that could change scope or the recommended direction

3. questions owned by someone who is not in the regular project meetings

4. questions that have passed their answer date

5. questions that have stayed open through two review cycles

Do not read every row aloud. Use the log to focus the conversation on uncertainty that requires attention. The client should leave knowing which answer matters next and who owns it.

Record the answer where the question started

When an answer arrives, update the original entry. Include the confirmed answer, the source, and the date. A link to an approved document, dataset, or written client response is more useful than “resolved in meeting.”

Then move any downstream work into the right record. A confirmed choice belongs in the decision log. A new commitment belongs in the action tracker. A problem that is already affecting delivery belongs in the project issue log.

Keep answered questions available for the life of the project. They explain why the team proceeded with a particular assumption and prevent the same uncertainty from resurfacing without context.

Close questions that no longer matter

Not every question needs an answer. The project may change direction, a deliverable may leave scope, or a later decision may make the question irrelevant.

Mark those items “no longer needed” and record why. Do not delete them. The closed record shows that the team made a deliberate choice instead of overlooking the question.

This is especially useful during a handover. The next owner can distinguish unresolved uncertainty from a question the project intentionally stopped pursuing.

Turn uncertainty into managed work

An open questions log will not remove uncertainty from a consulting engagement. It will stop uncertainty from hiding.

Give each question one owner, one reason, and one answer deadline. Review the items that could change the next milestone. Record confirmed answers where the question began, then move decisions and actions into their proper logs.

That small discipline keeps the project honest. The team knows what it does not know, the client can see what needs attention, and both sides can act before an unanswered question becomes a delivery problem.