Assumption Log
An assumption log records the things a plan treats as true without having confirmed them. Each entry states the assumption, who made it, what the plan depends on it for, how and when it will be validated, and its status. Assumptions that prove false are normally converted into issues, with a reference back to the original entry.
Every estimate rests on assumptions. The environment will be available in March. The vendor will supply test data. Two of the three legacy interfaces can be retired rather than rebuilt. None of these are facts when the plan is written, and the log exists so that the plan can be traced back to them when one turns out to be wrong.
What it contains
| Field | What it records |
|---|---|
| Assumption ID | Reference used from the plan, the business case and the RAID log |
| Statement | The assumption written as a testable claim, not as a hope |
| Area | Scope, schedule, cost, resource, technical, commercial or business |
| What depends on it | The estimate, milestone or design decision that would change if it were false |
| Made by and date | Who made the assumption and when, which matters when it is challenged later |
| Owner | The person responsible for confirming or disproving it |
| Validation action | What would settle it — a confirmation, a test, a contract clause, a data profile |
| Validation date | The date by which it needs to be settled, usually earlier than people expect |
| Confidence | How firmly it is held, which separates the working guesses from the near-certainties |
| Impact if false | What breaks, expressed in days, cost or scope where possible |
| Status | Open, validated, invalidated, with the resulting risk or issue reference |
How it is used
Assumptions are captured densely at the start — during business case, charter and planning — and then thinned out as they are validated. A useful log is largest in the first month and shrinks steadily. The Business Case Template (Excel) carries an explicit assumptions tab for exactly this reason: the benefit numbers in a business case are assumptions, and after approval nobody can reconstruct what they rested on unless they were written down.
In review, each open assumption is checked against its validation date. Anything past its date and still unvalidated is either escalated or converted to a risk with a probability attached. That conversion is the mechanism that stops assumptions from quietly becoming load-bearing. The RAID log guide covers how the A column relates to the other three.
Where it goes wrong
The most common problem is that the log is empty. Assumptions are made in conversation, in estimating sessions and in vendor calls, and nobody writes them down because at the time they feel like facts. Six months later the schedule is late and there is no record of what it was built on.
The second is assumptions written so broadly that they cannot be validated. "The business will be available to support testing" cannot be confirmed or disproved. "Four named finance users are released half-time from 6 April to 15 May for UAT" can be, and someone can be asked to sign it.
The third is treating validation as optional. An assumption with no validation date is a statement of faith. The fourth is failing to close the loop: when an assumption is invalidated, the estimate or milestone that depended on it needs revisiting, and without the "what depends on it" field nobody knows which one that was.
Related terms
See also RAID log, risk register and dependency.
Questions
What is the difference between an assumption and a risk?
An assumption is something the plan treats as true; a risk is something that might happen. An assumption that is challenged and found doubtful usually becomes a risk.
What happens when an assumption proves false?
It is marked invalidated and an issue is raised, referencing the assumption. Anything in the plan that depended on it — an estimate, a milestone, a design choice — is then reassessed.
Where do assumptions get recorded?
Usually in the A column of a RAID log, or in a dedicated tab of a business case or project charter where the estimates that rely on them are held.
How many assumptions should a project log?
Enough that the plan can be reconstructed from them. In practice most projects under-record rather than over-record, particularly in the first weeks.