This guide covers everything you need to know about the assumption log in PMBOK 8. The assumption log is one of the first documents created on any project — it captures the beliefs, conditions, and constraints that the team is treating as true without proof, and tracks them throughout the project lifecycle so risks can be managed proactively.
What Is the Assumption Log?
The assumption log is a project document that records all assumptions and constraints identified during project planning and execution. An assumption is any factor considered true, real, or certain for planning purposes but not yet verified. A constraint is any limiting factor that affects how the project team can execute the project.
The assumption log is not a one-time artifact — it is a living document updated as new assumptions are identified or existing ones are confirmed or invalidated. When an assumption is proven false, it may trigger a risk response or a change request, making the log a critical input to risk management.
Without an assumption log, projects operate on hidden beliefs. When those beliefs are wrong, the team is caught off guard. Documenting assumptions forces clarity and creates an early-warning system.
Assumption Log in PMBOK 8 — Domain and Process
In the PMBOK Guide 8th Edition, the assumption log belongs to the Governance Performance Domain and is first produced during the Initiate Project or Phase process. PMBOK 8 places greater emphasis on iterative refinement of assumptions across the project lifecycle, recognizing that assumptions evolve as stakeholder input, environmental data, and project realities become clearer.
The assumption log feeds directly into the risk register — each unverified assumption is a potential risk. It also informs the project scope statement and the project management plan, ensuring that planning decisions are grounded in documented, reviewable beliefs.
Key Elements of the Assumption Log
A well-structured assumption log typically includes:
- Assumption ID — a unique identifier for tracking and referencing each entry
- Assumption or Constraint Description — a clear, specific statement of what is being assumed or constrained
- Category — the area affected (scope, schedule, budget, resources, technology, stakeholders, etc.)
- Impact if Invalid — what happens to the project if this assumption proves false
- Owner — the team member responsible for monitoring and validating this assumption
- Status — open, confirmed, invalidated, or converted to risk
- Validation Date — when the assumption was last reviewed or confirmed
Assumption Log Example — Project Phoenix
In Project Phoenix, a $72,250 website launch managed by Alex Morgan, PMP, for TechCorp CEO Sarah Chen, the assumption log was created on day one of initiation. It captured 14 assumptions across scope, technology, and resources — including the assumption that BrightFrame Design Studio would be available for the full engagement and that the existing hosting contract with CloudHost Pro would cover the new site’s traffic requirements.
By week six, two assumptions had been invalidated: the development team’s availability assumption changed when John Tran took unplanned leave, and the CDN performance assumption was revised after load testing. Both invalidations were converted to risk register entries with mitigation plans, allowing Alex to keep the project on track and deliver under budget. The assumption log was reviewed in every biweekly status meeting, taking less than five minutes but preventing multiple downstream surprises.
You can download the complete filled-in example below — it shows exactly how the assumption log was applied in a real project context.
Download Free Assumption Log Template and Example
We have prepared two free resources to help you apply the assumption log on your own projects:
- Download the Assumption Log Template — PMBOK 8 (blank, ready to fill in)
- Download the Assumption Log Example — Project Phoenix (filled in for a real $72K website launch)
Both are free downloads — no registration required.
Assumption Log — Best Practices and Common Mistakes
The most effective assumption logs are specific, not vague. Instead of writing “the vendor will deliver on time,” write “BrightFrame Design Studio will deliver all design assets by April 15, 2024, as agreed in the SOW.” Specific assumptions are testable; vague ones are not. Review the log at every status meeting and assign a clear owner to each assumption so nothing falls through the cracks.
A common mistake is treating the assumption log as a one-time checklist created during initiation and never reviewed again. Another is conflating assumptions with requirements — assumptions are unproven beliefs that carry risk, not agreed-upon deliverables.
The assumption log is most effective when it is actively maintained and linked to the risk register so that invalidated assumptions trigger formal risk responses. Teams that skip or rush this document often discover late in the project that they were building on false beliefs, leading to costly rework and scope disputes.
Want to master project management with PMBOK 8? The PMBOK Guide 8th Edition is the definitive reference. Get your copy and use it alongside these free resources.
Free Template & Filled-In Example
Apply what you’ve learned with these two free resources:
- Download the Free Assumption Log Template (PMBOK 8) — Ready-to-use blank template for your next project.
- Download the Filled-In Example — Project Phoenix — See exactly how this document was completed for a real $72K website launch project.
Project Management