September 7, 2026 · 6 min read
TL;DR: Assumptions appear in 20 of the bank's answer options: 6 keyed, 14 wrong. The keyed ones name an unverified belief as the cause of a failure, or verify assumptions at the right moment, which is the start of a phase. The wrong ones respond to a broken assumption with a budget increase or a message to stakeholders before anyone has reworked the plan.
An assumption is something taken to be true for planning purposes without having been verified. That definition is doing more work on the exam than most candidates expect, because it is what separates an assumption from a constraint, and one bank item is decided entirely on the distinction.
A constraint is a known limitation you must work within. An assumption is a belief you have not checked. The bank decides one whole item on that difference.
A team draws up a detailed plan to upgrade the operating system on every company computer, then discovers not all the machines can run the new version. The item asks which statement best describes what happened, and offers four diagnoses: the team made a wrong assumption, failed to develop an appropriate project plan, failed to establish an adequate risk response, or failed to treat the new OS version as a constraint.
Keyed: the team made a wrong assumption. They planned on the belief that every machine could run the new version, that belief was never tested, and when it proved false the plan built on it failed. That is exactly how assumptions cause damage and why they are recorded in an assumption log and validated.
The three distractors each mislabel it in a way worth learning. A constraint is a known limitation the project must work within, not a belief that turned out to be wrong. The risk-response option describes managing a risk that was never identified in the first place. And the plan was not inadequate as a plan; it was well built on a false input.
If you remember one thing: a constraint is something you know is true and must work around. An assumption is something you believe is true and have not checked.
At the start of a phase, not the end. One bank item tests only that.
It asks which activity would NOT happen at the end of a phase in a predictive life cycle, offering verifying the project assumptions, ensuring each deliverable is verified and ready, ensuring each deliverable is accepted by the sponsor or customer, and communicating status to key stakeholders.
Keyed: verifying the project assumptions. At the start of each phase, the governance system confirms the current assumptions still hold and that remaining risk is acceptable before proceeding. The end of the phase is for readiness, acceptance, and communication.
It is a small piece of doctrine with a practical shape behind it. Checking your assumptions after you have finished the work is checking whether you should have done what you already did.
Rework the plan, before you touch money or stakeholders. During a bridge-strengthening project, a documented planning assumption, that the existing piers could carry the additional load without modification, proves wrong. Correcting it has cost consequences.
Keyed first action: re-evaluate the plan against the corrected information to establish the cost impact. The reasoning generalises well beyond bridges. A wrong assumption rarely affects cost alone; it usually reaches into the schedule, the design and the risk register as well, and the size of the cost change only becomes visible once the plan has been reworked against the truth. Any budget change or funding request has to rest on that.
Three distractors, three ways to skip it. Increase the budget immediately to cover the corrected assumption. Tell the stakeholders costs will rise and ask for additional funding. Continue and reconcile the financial differences during closure. The first two put a number on the table that has not been derived; the third defers a known problem to the point where nothing can be done about it.
Common trap: treating the assumption log as the document that answers a scope question. A landscape architect unsure what they are meant to be working on needs a document giving a detailed description of the scope, who it is assigned to, the acceptance criteria, and the resource requirements. The assumption log is offered and loses to the WBS dictionary, which holds exactly that list. The assumption log records what the project believes without proof, along with constraints. It is a register of unverified beliefs, not a work instruction, and this bank offers it as a plausible-looking scope artifact more than once.
Five scenarios where an assumption-flavoured option is offered and beaten, with what the bank keys instead.
| Scenario | Assumption option offered | Keyed |
|---|---|---|
| Machines cannot run the new OS after detailed planning | Failed to treat the OS version as a constraint | The team made a wrong assumption |
| End of a phase in a predictive life cycle | Verifying the project assumptions | That is the one that does NOT belong there |
| Documented pier-load assumption proves wrong | Increase the budget immediately | Re-evaluate the plan against the corrected information |
| Architect does not know what to build | The assumption log | The WBS dictionary |
| Regulatory restriction may or may not apply | Proceed assuming the restriction will not apply | Establish whether it applies |
The last row is the everyday version of the whole topic. Proceeding on the assumption that a restriction will not apply is offered as an answer, and it fails for the same reason the OS upgrade failed: nobody checked. An assumption is not a decision. It is a placeholder for one, and the exam keeps asking whether you noticed the difference.
What is the difference between an assumption and a constraint? A constraint is a known limitation the project must work within. An assumption is a belief taken as true for planning without being verified. One bank item turns on exactly that: a team that planned as if every machine could run a new OS made a wrong assumption, not a constraint error.
When are assumptions verified in a predictive life cycle? At the start of a phase, not the end. The governance system confirms the current assumptions still hold and remaining risk is acceptable before proceeding. The end of a phase is for verifying and accepting deliverables.
What should you do first when a documented assumption turns out to be wrong? Re-evaluate the plan against the corrected information. A wrong assumption rarely affects cost alone, so the size of any cost change only becomes visible once the plan has been reworked against the truth.
What goes in the assumption log? The beliefs the project is planning on without having verified them, together with constraints. It is a register of unverified inputs, which is why it loses to the WBS dictionary when a question asks what somebody is actually meant to build.
PMP Practice's 2,141 questions are certified against PMBOK 8 and the July 2026 ECO, with every wrong answer explained rather than just marked wrong. Start the free 20-question sample — no card, no signup required to try it.
Related reading: The Project Management Plan: What's In It, Who Owns It, and What a Baseline Actually Is and Risk Management: Probability and Impact, Not Just the Matrix. Planning is mapped on the Process domain study page.
What is the difference between an assumption and a constraint?
A constraint is a known limitation the project must work within. An assumption is a belief taken as true for planning without being verified. One bank item turns on exactly that: a team that planned as if every machine could run a new OS made a wrong assumption, not a constraint error.
When are assumptions verified in a predictive life cycle?
At the start of a phase, not the end. The governance system confirms the current assumptions still hold and remaining risk is acceptable before proceeding. The end of a phase is for verifying and accepting deliverables.
What should you do first when a documented assumption turns out to be wrong?
Re-evaluate the plan against the corrected information. A wrong assumption rarely affects cost alone, so the size of any cost change only becomes visible once the plan has been reworked against the truth.