“Free Assumption Log Template With Real Examples”

What is an assumption log, and how is it different from a risk register?

free assumption log template is a key topic in modern project management and teamwork. An assumption log records beliefs a plan depends on but has not confirmed. A risk register records events that may happen and would hurt if they did. The difference is grammatical and practical: assumptions are stated as true until proven false, risks are stated as possible and uncertain.

That distinction changes the action. A risk gets mitigated (buy insurance, add a buffer, define a fallback). An assumption gets tested (run the spike, call the vendor, read the contract). Logging an assumption in a risk register usually produces the wrong response: someone adds contingency to the schedule instead of spending two days finding out whether the API can return 50,000 rows in under 400 milliseconds.

Three states matter. An assumption is unverified. A validated assumption becomes a fact you can cite in the plan. An invalidated assumption becomes either a risk, an issue, or a scope change — and it should be moved, not left in the table as a red row that everyone learns to ignore.

The log also has a social function. It gives a junior engineer a legitimate way to say “we are assuming the client’s data is clean” without contradicting a senior colleague in a meeting. The row is neutral; the argument moves into the test column.

What columns does the template need?

Two columns do most of the work. “Impact if false” forces a number, and numbers can be compared. “Validation test” forces an action, and actions have owners. Without those two, the log becomes a diary.

Nine columns are enough for a 20-person project. A 200-person programme usually adds a dependency link, a decision reference, and a “consequence if invalidated” field that names the specific plan section that changes. Resist adding more until the review meeting is spending time on the wrong rows.

What does a filled-in log look like?

Read the table as a queue, not a record. A-07 has the largest exposure and therefore first claim on attention, even though its confidence is higher than A-11’s. A-18 is validated and stays in the log only because the plan still cites it; once the plan text is updated, the row can be archived.

The exposures sum to $30,810. That total is not a budget line, because the assumptions are not independent and not all will fail. It is a ranking device, and a starting point for a reserve calculation explained below.

How do you turn confidence into a number you can defend?

Ask the owner a single question: “If we ran this project ten times, in how many would this hold?” The answer is the confidence percentage. It is subjective, and that is fine, because consistency matters more than precision — the same person scoring 20 assumptions on the same afternoon will produce a usable relative ranking even if the absolute numbers are off.

Two calibration rules keep scores honest. First, ban 100% and 0%: nothing is certain, and a 0% assumption is a known problem, not an assumption. Second, cap anything above 90% unless it is contractual or already tested, because teams systematically overstate confidence on things they have not checked.

Impact should be expressed twice where possible: in working days, then converted at the squad’s burn rate. A five-person squad with a loaded cost of $520 per person-day burns $2,600 per working day. Ten days of delay is therefore $26,000, not “significant”. The conversion makes an assumption comparable to a change request, which is the language that gets decisions made.

Exposure is simply failure probability × impact. At 70% confidence, failure probability is 30%, so a $26,000 impact gives $7,800 of expected exposure. This is the same expected-value logic used in insurance and portfolio management, and it behaves the same way: it is not a prediction, it is a way to rank.

Which assumptions actually matter to a plan?

The ones that are both uncertain and expensive. A high-confidence assumption with a large impact deserves a monitoring trigger rather than a test. A low-confidence assumption with a small impact can be accepted and forgotten. The interesting quadrant is low confidence, high impact — that is where tests buy the most information per dollar.

Worked example 1 — the SAML spike. A-04 assumes the client’s identity provider supports SAML 2.0 and can be configured in three days. The team rates it 70% likely. A ten-day slip costs 10 × $2,600 = $26,000, so exposure is 0.30 × $26,000 = $7,800. A two-day spike by one engineer costs $1,040. If the test moves confidence to 90%, exposure falls to 0.10 × $26,000 = $2,600, a reduction of $5,200. Net value of the test is $5,200 − $1,040 = $4,160, a return of about 4:1 on the effort.

Worked example 2 — the joint probability problem. A launch plan depends on five assumptions, each rated 85%. The probability that all five hold is 0.85^5 = 0.444, or 44%. Raise three of them to 95% through cheap tests and the joint figure becomes 0.95^3 × 0.85^2 = 0.857 × 0.7225 = 0.62, or 62%. Two days of testing moved the plan’s overall credibility by 18 points, which is more than any status report can do.

Worked example 3 — the reserve calculation. The five open exposures total $30,810. A blanket reserve of 60% would be $18,486, but assumptions overlap: if A-07 fails, A-04’s delay is absorbed by the same slack. A defensible method is to reserve against the two largest independent exposures plus 20% of the rest: $9,750 + $8,320 + (0.2 × $12,740) = $20,618. Compare that with the common alternative, a three-week schedule buffer worth 15 × $2,600 = $39,000. The log produces a reserve less than half the size of the buffer, because it names what the money is for.

Worked example 4 — ranking tests by return. Test A-04 returns 4.0 dollars of exposure reduction per dollar spent. Test A-11 costs $1,040 and moves confidence from 60% to 85%, cutting exposure from $8,320 to $3,120 — $5,200 saved, a return of 5.0. Test A-07 costs $1,320 and moves confidence from 75% to 90%, cutting exposure from $9,750 to $3,900 — $5,850 saved, a return of 4.4. Run A-11 first, then A-07, then A-04. The ranking is not intuitive; A-11 has the lowest confidence but the best return, because its test is cheap and its impact is large.

Which validation tests are worth running?

The decision rule is the part most teams skip. Without a threshold, tests become optional, and optional work loses to delivery pressure every time. The “expected reduction must exceed twice the cost” rule is deliberately conservative: it prices in the fact that tests are often inconclusive, and it stops a team from spending three days proving something that would have cost two days to fix.

When should an assumption move to a risk or an issue?

Move it the moment its status changes, and change the plan text at the same time. An invalidated assumption that stays in the log is worse than no log, because it teaches the team that rows are decorative.

The routing is straightforward. If the belief is false and the work is already affected, it becomes an issue with an owner and a recovery action. If it is false but the impact is still in the future, it becomes a risk with a mitigation and a trigger. If it is false and the scope must change, it becomes a change request with a cost, which is the only version a client can approve. If it is true, it becomes a fact — cite it in the plan and remove the row at the next review.

One rule saves arguments: an assumption may only be closed by evidence, never by confidence. “We’re pretty sure the API is fine” is not a validation. A test result, a signed email, or a sample query output is.

What are the trade-offs of keeping an assumption log?

• Coverage versus weight. A 60-row log is comprehensive and unreadable. Cap the active list at 15 rows and archive the rest; a log nobody reads changes no decisions.
• Precision versus honesty. Multiplying a subjective confidence by an estimated impact produces a number that looks scientific. It is a ranking device, and saying so out loud protects the log’s credibility.
• Speed versus safety. Testing costs days. On a two-week discovery, tests should focus only on the assumptions that would kill the plan, not on every uncertain detail.
• Transparency versus politics. Naming an assumption can read as blame, especially when it concerns someone’s availability or a supplier’s competence. Write assumptions about the plan, not about people.
• Maintenance versus value. A log updated once at kickoff is a fossil. Fifteen minutes in a weekly review, with the same three questions each time, is the minimum viable cadence.

How do you run the log week to week?

Keep the ritual short and identical every time. Ask which assumptions are now testable, which tests finished, and which rows changed status. Then pick at most two tests for the coming week, ranked by return, and assign them in the meeting.

Tie the log to gates rather than to calendar dates. A design gate is not passed until the top three assumptions are validated or explicitly accepted with a reserve attached. A build gate is not passed until every assumption with exposure above $5,000 has either a test result or a named owner watching a trigger.

The archive matters as much as the active list. When a project closes, the invalidated assumptions are the most useful document you own, because they are the specific reasons the plan moved. Next time, they become the first rows of the new log — and the second project starts with fewer surprises at the same cost.

How does Doitify support this workflow?

Doitify is our product, so treat this section as disclosure rather than review. It is a single workspace for projects, tasks, sub-tasks, checklists, owners, and due dates, with Kanban, Gantt, roadmap, calendar, and workload views, work and performance reports, automations, project documents, and import and export. Doitify Copilot and AI Coach turn a stated goal into tasks, sub-tasks, and a plan.

The assumption log works well as a project document with a table and a linked task per validation test. What the tool adds is the link between the row and the work: a test becomes a dated task with an owner, its result becomes a comment on the document, and the trigger date becomes a due date that appears in the week it matters. The template itself is free and lives in any spreadsheet; the value of a tool is that the test does not quietly disappear when the sprint gets busy.

Conclusion

An assumption log earns its place when it changes what the team does next week. That happens only if every row carries a number and a test, and if the review meeting ends with two named tests rather than a general sense of concern.

Start with the five assumptions that would most change the plan if they were false. Score them, price them, and test the two with the best return. The remaining rows can wait, and most of them will resolve themselves by being written down — which is the cheapest validation method available.

If this post on free assumption log template was helpful, you might also enjoy What Is a Project Charter? Definition, Purpose, and Examples and Free Project Schedule Template.