Open Questions and Assumptions Log: Keep Unknowns Visible
ยท 7 min read
An open-questions log lists what you do not know yet, with a named owner and a due date for each item. An assumptions list records what the plan treats as true without proof, and which part of the estimate depends on it. Keep both from the first discovery call, review them every week, and close or carry forward every item before sign-off. Most scope arguments later in a project start with an unknown that nobody wrote down.
Why unknowns cause disputes
During discovery everyone hears the same unknowns: "We think the legacy system has an export." "Legal still has to confirm whether we can store this data." "Marketing may want a second language." People say these things on calls, everyone nods, and the conversation moves on.
Three months later the build team finds the legacy system has no export. The client remembers the plan as covering the integration. The vendor remembers it as resting on an assumption. Neither can show a written record, so the gap turns into a debate about the contract rather than a planned change.
Writing unknowns down does not make them go away. It changes who is surprised. A logged assumption that turns out false is a known risk with an agreed next step. An unlogged one is a dispute.
Project management practice treats this as a standard document: an assumptions log started at project initiation, with each entry's date, impact and owner, kept up to date as the project runs (a short guide to project assumptions). You do not need a heavy process for it. You need a list that people actually read.
The open-questions log
Keep it to three required columns, plus a few optional ones:
| Question | Owner | Due | Blocks | Answer |
|---|---|---|---|---|
| Does the payment provider support partial refunds? | Client finance lead | 14 Nov | Refund flow (REQ-12) | |
| Who approves copy changes on the checkout page? | Client marketing | 7 Nov | Nothing yet | |
| Can we use the existing customer database for log-in? | Client IT | 10 Nov | Architecture decision on sign-in |
Rules that keep it useful:
- One question per row, phrased so it can be answered with a fact or a decision. "What about payments?" is not a question; "Which payment provider do we integrate with?" is.
- The owner is a person, not a team. "Client IT" is fine as a label as long as one person there has agreed to answer.
- A due date, even a rough one. A question with no date stays open forever.
- "Blocks" says what waits for the answer. This is what lets you rank the list.
- The answer is written into the row. Then the row is closed. Do not delete it, because the record of what was decided and when is the point.
Review the log at the end of every discovery workshop and in a short weekly check. New questions come up all the time; what matters is that they land in the log the same day.
The assumptions list and how it ties to the estimate
An assumption is different from a question. A question is something you will get an answer to. An assumption is something you decide to treat as true so the plan can go on, usually because checking it would take longer than discovery has.
Each assumption should say three things: what you assume, what in the plan depends on it, and what changes if it is wrong.
- "The client's product API returns stock levels in real time. Depends: milestone M2 (catalogue). If wrong: add a nightly sync job, roughly 3-5 person-weeks."
- "Two backend and one frontend developer from week 1. Depends: every milestone date. If wrong: dates move proportionally."
- "No content migration from the old site. Depends: M4 (launch). If wrong: migration becomes its own milestone, to be estimated."
- "No holiday freeze in December. Depends: the release date."
The "if wrong" part is what makes an estimate honest. A range of 30-40 person-weeks is only a range under those assumptions. When an estimate goes to a client or into a contract, the assumptions list should go with it. If you price the work as fixed, the assumptions mark where the price stops.
Some assumptions are really constraints: limits the team cannot change, such as a regulation, a fixed platform or a budget cap. Keep them in the same list but label them, because a constraint is not something you test. It is something you design around.
In Discovery Phase AI, the roadmap stage keeps assumptions as one-line entries beside the milestones and their low-high person-week estimates, so they appear in the same place as the numbers they qualify. A spreadsheet tab beside the estimate does the same job if you keep it current.
Blockers: the unknowns that stop work
Some open questions are urgent. They stop a milestone or a decision from going ahead. Track them as a separate type so they cannot hide in a long list:
| Type | What it means | Example | How fast it needs attention |
|---|---|---|---|
| Open question | Something not yet known | Who approves checkout copy? | By its due date |
| Risk | Something that may go wrong | The vendor's API may be rate-limited | Watch, plan a response |
| Blocker | Something that stops work now | No test account for the payment provider | Escalate this week |
A blocker needs an owner with the power to remove it, which is often someone more senior than the person who raised it. If a blocker sits for more than a week, the delivery plan is already wrong, and the people who own the plan should hear it from you first.
Discovery Phase AI keeps blockers, risks and open questions as one typed list per project. Each item is either Active or Resolved and can point at the stage it came from. You can also create an item by selecting a sentence in a stage, such as a requirement that depends on an unconfirmed fact. Here is that list in the example report, made for an invented project called Fieldwise:
Closing items before sign-off
Before the client signs off on discovery, go through both lists item by item. Every entry ends in one of three states:
- Answered or confirmed. The answer is written in, and anything it changed (a requirement, an estimate, a decision) has been updated.
- Accepted as a known unknown. The client and the team agree it stays open into the build. It needs an owner, a date and a note in the scope or estimate saying what happens if the answer goes the wrong way.
- Dropped. It no longer matters because scope changed. Say so in the row.
Nothing stays open just because nobody looked at it. Discovery Phase AI enforces this at the project level: a project cannot be marked done while any blocker, risk or open question is still active. Even without a tool, a simple rule works: sign-off happens only when every row has a state.
The discovery phase checklist asks about both lists in its estimates section:
For where these lists fit among the other discovery outputs, see the discovery phase in software development.
Hand both lists to the build team with the rest of the discovery document. To them, the open items are the most useful part: they show where the plan is still soft.