Assumption Log vs Risk Register
Teams argue about where an item belongs, put it in whichever register is open, and move on. The distinction is worth twenty seconds of thought, because the two records drive completely different behaviour: one produces validation activity with dates against it, and the other produces responses to uncertain events.
Section 4 of the PMBOK® Guide Eighth Edition carries both among its artefacts. The practical relationship between them is the useful part, because most project surprises begin their life in the first and should have moved to the second.
What each one records
An assumption is something the project has decided to treat as true without having verified it. The legacy interface is documented. The client's reference data is clean enough to migrate. The test environment will be available from June. Planning rests on each of these, and each can be checked, which is what makes them assumptions rather than risks. A good log records who made the assumption, what depends on it, how it will be validated and by when.
A risk is an uncertain event or condition that would have an effect if it occurred. It carries a probability, an impact and a response, and nobody can make it go away by checking something, which is precisely the difference. Risks are managed; assumptions are resolved.
Three tests for where something belongs
Can somebody check it this month? If yes, it is an assumption and the entry should carry the name of the person who will check and the date. If nobody can establish it by investigation, it is uncertainty about the future, which belongs in the risk register.
Is the project already relying on it? Assumptions are load-bearing by definition: the plan is built on them. A risk is something that might happen and the plan does not currently depend on it happening or not.
Does it have a consequence if wrong? An assumption with no consequence is a detail. An assumption with a serious consequence, still unverified after the point where it could have been checked cheaply, has become a risk and should be entered as one, with the assumption entry cross-referenced. That migration, from log to register, is the single most valuable piece of maintenance either record receives.
Twelve boxes nobody opened
A software company was implementing a case management platform for a client, and the implementation plan included a data migration from a system that had been in service for about fourteen years.
The assumption, recorded properly at initiation, was that the client's historical records were structurally consistent and could be mapped with a standard transformation. It was a reasonable assumption, it came from the client's own IT team, and it was written in the log with an owner and no validation date.
Sample data had been provided as printed listings in a dozen archive boxes, which sat along the wall of the implementation floor. Three had been opened during the sales phase. The other nine kept their tape seals for five months.
When the migration build started, the nine boxes were opened in an afternoon. About a fifth of the records used a numbering convention that had been superseded in 2014, and roughly four thousand of them carried free-text entries in a field the new system expected to be a code. The transformation needed for those was a piece of work in its own right, about seven weeks of it, and none of it was in the plan.
The failure was not the assumption; assuming reasonable data quality at bid stage is normal. The failure was that the assumption had no validation date, so nothing ever triggered somebody to open the other nine boxes, and it never converted into a risk that could have been assessed and mitigated while options were cheap.
What the company changed was a single column in its template. Every assumption now carries a validate-by date and an owner, and the weekly review lists any that have passed their date. On the next implementation that column caused three boxes to be opened in week two.
Keeping the assumption log alive
Give every entry a date and an owner. Without those, an assumption log is a list of things the project has agreed not to think about, which is the condition of most of them by month three.
Review it at planning points, not only at initiation. Each stage, phase or major planning event is a natural moment to ask which assumptions are now checkable, which have been proved, and which have quietly become risks. That review takes about fifteen minutes and it is where the log earns whatever it cost to write.
For a PMP® candidate, it helps to recognise that assumptions can be verified and risks are managed, so a scenario describing a surprise that could have been checked earlier is describing an assumption that was never validated. A response that adds the item to the risk register after the fact records the problem without preventing the next one. Situations where the entry exists in a log and nothing ever acted on it are a familiar sight in a structured PMP exam preparation course.
Open your assumption log this week and look for entries with no validation date. Pick the three whose failure would hurt most, put a name and a date against each, and you will have done more for the project than a month of risk scoring.
Interested in going further?
Most unpleasant surprises were written down early, in the right place, with nobody assigned to check them. Omega's PMP® Exam Preparation works through assumptions and risks as two different kinds of work.
Assumption logs and risk registers are both described in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A170: Decision Log: The Forgotten Project Control
A155: Risk Register vs Risk Report vs Issue Log: What Goes Where?
A171: Change Log vs Issue Log
A172: Lessons Learned Register: Use It Before the Project Ends
A167: Project Charter Explained: Purpose, Content and Common Misunderstandings
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
