Complex office work often begins before every fact is available. You may know the deadline but not the final scope, have most of the data but not the last source file, or understand the requested outcome while still making reasonable guesses about audience, format, ownership, and approval. The problem is not that assumptions exist. The problem is that they stay invisible until someone challenges them after hours of work have already been invested.
An assumption log is a simple way to make those working guesses visible without stopping progress. It is not a heavy project document. For most assignments, it can be a short table or note that records what you are assuming, why the assumption is reasonable, what would change if it proves wrong, and when it should be confirmed. Used well, it reduces rework and makes uncertainty easier to manage.
Separate Known Facts From Working Assumptions
Start by distinguishing what you know from what you are temporarily treating as true. A fact has a clear source: an approved brief, a confirmed deadline, a signed contract, a published policy, or an authoritative data set. An assumption fills a gap where that certainty does not yet exist.
For example, “The client review is on Friday at 3 p.m.” may be a fact if it is on the confirmed calendar invitation. “The client wants a five-slide summary” is an assumption if nobody specified the format and you are inferring it from the previous review.
This distinction matters because people often defend an assumption as though it were an instruction. Once the assumption is written down, it becomes easier to ask, “Is this still the best working basis?” rather than arguing about who misunderstood whom.
If the assignment itself is too vague to support a reasonable assumption, clarify it first. The discipline in clarifying a vague work request before you start helps establish the outcome, audience, format, and real deadline before you begin filling smaller gaps.
Record Only Assumptions That Could Change the Work
An assumption log becomes useless if it captures every minor guess. Focus on assumptions that could materially change scope, effort, timing, cost, quality, or the final recommendation.
Typical examples include the reporting period you are using, which source is authoritative, whether a stakeholder needs to approve the output, whether a dependency will arrive by a certain date, which customer segment is in scope, or whether a requested figure should be shown gross or net.
A useful test is: if this assumption is wrong, would I redo meaningful work or make a different decision? If the answer is no, you probably do not need to record it.
Use Four Fields for Each Assumption
You do not need a complicated template. Four fields are usually enough:
- Assumption: the statement you are currently treating as true.
- Basis: why it is reasonable for now.
- Impact if wrong: what would need to change.
- Confirmation point: who or what can confirm it, and by when.
For example: “Assumption: use August actuals rather than the September forecast. Basis: the manager asked for a performance review, not a forward plan. Impact if wrong: charts and commentary would need to be rebuilt. Confirmation point: confirm with the manager before the analysis section is finalized.”
This structure makes the assumption actionable. It tells you whether you can safely continue and when the uncertainty must be resolved.
Do Not Turn the Log Into a Permission Queue
The purpose of an assumption log is to keep work moving, not to create a new approval process. Some assumptions can remain provisional while you progress. Others must be confirmed before a high-cost or irreversible step.
Classify assumptions mentally into two groups: safe to proceed and must confirm before commitment. You can draft a report while waiting for confirmation of one minor data label. You should not sign off a client price if the currency assumption is unresolved.
This is where judgment matters. The higher the cost of being wrong, the earlier the assumption should be confirmed.
Make the Consequence of a Wrong Assumption Visible
People are more likely to answer a confirmation request when they understand why it matters. “Can you confirm whether we are using the approved budget?” may feel optional. “Can you confirm whether we are using the approved budget or latest forecast? The choice changes the variance calculation in every chart” explains the decision cost.
That same principle makes a good decision brief: show the decision boundary and the consequence, not just the background.
You do not need to dramatize every assumption. A short impact statement is enough to separate important uncertainty from ordinary detail.
Confirm High-Risk Assumptions Early
Some assumptions deserve immediate attention because they can invalidate a large amount of downstream work. These often involve scope, authoritative data, customer commitments, legal or policy constraints, approval authority, and hard deadlines.
Before spending hours on execution, scan your assumption log and identify the one or two items with the largest downside. Confirm those first.
This complements a project pre-mortem. A pre-mortem asks what could cause the project to fail; an assumption log identifies the unverified beliefs that could make your current plan wrong. The two techniques overlap, but the assumption log is lighter and can be maintained throughout everyday work.
Update the Log When New Information Arrives
An assumption log should not preserve uncertainty that has already been resolved. When a stakeholder confirms the format, a data source becomes final, or an approval is granted, mark the assumption as confirmed and record the source if useful.
If the assumption is disproved, record the replacement fact and adjust the work. Do not simply delete the old assumption if the change explains why the plan shifted. A short note such as “Changed 7 Sep: Finance confirmed forecast basis instead of approved budget” can prevent confusion later.
The goal is a current working picture, not an archive of every thought you had.
Use Assumptions to Improve Your ETA
Estimates are often wrong because they are presented without the assumptions underneath them. “I can finish by Thursday” may really mean “I can finish by Thursday if the data arrives Tuesday and the scope does not expand.”
When an assumption materially affects timing, connect it to your estimate. The approach in giving a useful ETA without overpromising is useful here: state the estimate together with the dependency or condition that could move it.
For example: “I expect to send the first draft Thursday afternoon, assuming the customer data arrives by Tuesday noon. If it slips beyond that, I will update the ETA Wednesday morning.” This is more useful than either pretending certainty or refusing to estimate at all.
Share the Log Only at the Level People Need
Your personal working log can contain more detail than stakeholders need. Do not attach a long list of internal assumptions to every update. Surface the assumptions that affect their decision, input, or expectations.
A manager may need to know that the recommendation assumes no additional headcount. A client may need to know that the delivery estimate assumes approval by Friday. A teammate may only need to know which data source you are treating as authoritative.
Keep the full log where you manage the work, then communicate the relevant assumptions in normal project updates, briefs, or handoffs.
Review Assumptions Before the Final Handoff
Before you send finished work, scan the assumption log one last time. Ask three questions: Which assumptions are now confirmed? Which remain unresolved? Does the recipient need to know about any that remain?
If an unresolved assumption affects how the work should be interpreted, state it clearly. “The analysis uses provisional August figures and will be refreshed after Finance closes the month” is better than allowing the recipient to assume the numbers are final.
This final check also helps you catch stale assumptions. A condition that was reasonable on Monday may no longer be reasonable by Friday.
A Small Habit That Prevents Expensive Rework
You do not need an assumption log for every ten-minute task. Use it when the work has meaningful uncertainty, multiple dependencies, expensive rework, or decisions that depend on incomplete information.
The habit is simple: identify the few unverified beliefs that materially shape your plan, record why you are using them, note what changes if they are wrong, and define when they must be confirmed. That small amount of visibility lets you keep moving without pretending that every part of the assignment is certain.
Good work does not require eliminating all assumptions before you begin. It requires knowing which assumptions you are making and managing them deliberately.
Related JSW resource: If you need a reusable template for this process, explore the Office Control Logs & Trackers, which includes editable office logs that can help keep decisions and follow-up work visible. Check the product page for the full contents.