Most project teams document their assumptions and constraints at initiation and then forget about them. The assumption log gets created, added to the project charter, reviewed by nobody, and filed. The constraints section lists the obvious ones — budget, schedule, resources — and stays static from month one to close. This approach manages the documented assumptions and constraints reasonably well. It does nothing for the more dangerous category: the ones nobody wrote down because everyone assumed everyone else already knew them.
Table of Contents
The projects I’ve seen go seriously wrong rarely failed because of constraints that were clearly documented at the start. They failed because of assumptions that felt too obvious to record — and turned out to be wrong when it mattered most.
The Assumptions and Constraints Problem Nobody Names
When a project team sits down to document assumptions and constraints, they tend to capture the ones already on their minds. The budget ceiling. The regulatory deadline. The assumption that the client will provide review feedback within two weeks. These get written down, monitored, and managed — which is good.
What doesn’t get written down are the assumptions that feel like common knowledge. That the legacy system will interface with the new platform the way the architecture diagram suggests. That the department head who verbally supported the project at kickoff will still be in that role in six months. That the ground conditions match the desk study. Nobody writes these down because they seem too obvious — or, honestly, because writing them down would mean acknowledging uncertainty the team isn’t ready to sit with at initiation.
I worked on a software migration project where both the client’s IT team and the vendor had assumed, independently, that the source data was clean enough to migrate directly. Neither team documented it. Nobody validated it. When the data quality analysis came back — eight weeks into a twelve-week project — about 35% of records needed remediation before migration could proceed. The project ran four months over. It wasn’t complex. It was one undocumented assumption that two separate teams had made without telling each other.
Worth flagging now, though I’ll come back to it later: this is also a risk management story. Every undocumented assumption is a risk that never made it onto the risk register. That connection matters for how you run the assumption log, and I’ll explain the mechanism in the section on risks.
What Project Assumptions Actually Are
A project assumption is any factor you’re treating as true for planning purposes, without having verified it. The PMBOK Guide defines them as factors considered to be true, real, or certain without proof or demonstration. That’s precise enough, though “without” is doing a lot of work in that sentence. Assumptions aren’t necessarily wrong — most turn out to be correct. The problem is you won’t know which ones are wrong until you test them, and testing them costs time and resources that most teams don’t allocate for this at initiation.
Assumptions exist at every level of planning. At the strategic level: we assume this technology will be stable enough for production use by the time we need it. At the planning level: regulatory approval will take four to six weeks. At the task level: the vendor will deliver hardware by the date they quoted. Each is a belief held as fact for planning purposes. Each carries embedded risk.
The line that actually matters: a fact has been verified, an assumption hasn’t. When teams blur this — treating unverified beliefs as established facts — the assumption log stops functioning. An assumption that gets confirmed mid-project should be removed from the list or flagged as validated. One that turns out to be false should immediately become a risk or an issue, depending on whether it’s still ahead or has already materialized.
What Project Constraints Actually Are
A constraint is a fixed boundary the project must operate within. Unlike assumptions, constraints are known to be real — they don’t need to be verified, they need to be respected.
The familiar framing is the triple constraint: scope, schedule, cost. Every project has all three, and they pull against each other. Expand scope without adjusting schedule or budget and something breaks — usually the team’s working hours, or quality, or both. That’s not a risk; that’s a constraint being violated.
Beyond the triple constraint there are others worth naming: quality standards the output must meet, regulatory requirements the project must comply with, resource windows (specific people or equipment available only at certain times), and technical constraints that limit design choices. A construction project may be constrained by material strength specifications. A software project may be constrained by the hardware environment the solution runs on.
The defining characteristic of a constraint is that it’s non-negotiable within the current context. It can be changed — a budget ceiling can be raised — but only through a formal process with sponsor or client agreement. Treating a constraint as quietly negotiable, without that process, is how scope creep, budget overruns, and schedule slippage start. They don’t usually start with anyone deciding to break the rules. They start with someone assuming the constraint has a little more flexibility than it was stated to have.
Assumptions vs Constraints: The Distinction That Matters in Practice
The textbook answer on assumptions vs constraints is clean: assumptions are believed to be true, constraints are known to be true. In practice the line is less clear, and the confusion between them creates specific, recurring problems.
The most common one: treating a constraint as an assumption. A team knows the budget is fixed at $2.4M but plans as if there’s flexibility — assuming a scope reduction will be approved if costs run over, assuming the sponsor will find additional funds if needed. These aren’t assumptions about an uncertain future. They’re hopes attached to a known constraint. When the constraint holds and the hoped-for flexibility doesn’t materialize, the project has a structural problem, not just a cost problem.
The reverse also happens. A project manager was told informally that the project needs to finish by a certain date. Nobody confirmed whether that date was contractually fixed or a preference stated as a fact. The team planned around it as a hard deadline. Later, when a scope change created schedule pressure, there was no conversation about whether the date could flex — because everyone had been treating an assumption as a constraint. It might have been negotiable. Nobody checked.
| Assumptions | Constraints | |
|---|---|---|
| Nature | Believed to be true; unverified | Known to be true; fixed boundaries |
| Verification | Should be tested during the project | Already established; renegotiated only formally |
| Risk connection | Failed assumptions become risks or issues | Violated constraints become issues or change requests |
| Management | Tracked in assumption log; monitored continuously | Enforced; changes require formal process |
| Common example | “The vendor will deliver on the quoted date” | “The project budget cannot exceed $500,000” |
The Dangerous Ones: Assumptions Nobody Writes Down
Every assumption log has a gap. The documented assumptions are the ones someone raised. The undocumented ones are the beliefs the team holds collectively without anyone stating them explicitly — because they seemed too basic, too obvious, or too uncomfortable to name.
Uncomfortable assumptions are the most dangerous. If a project is planning around the continued availability of a key technical expert who’s been quietly looking at other roles, that’s an assumption. If nobody says it out loud because naming it would create awkward conversations, it stays undocumented. When the expert leaves at month four, the team treats it as an unexpected shock rather than a materialized risk.
There’s a technique I’ve used that helps surface these. At initiation, ask the team to complete two sentences: “This project will succeed if…” and “This project could fail if…” Both sets of answers contain assumptions. The “fail if” answers especially tend to surface the ones nobody was going to write down — beliefs about technical feasibility, stakeholder commitment, external conditions, organizational capacity. The ones people hold privately but haven’t said aloud.
Another gap opens at the planning-to-execution handover. The team that planned the project made assumptions they understood implicitly. The team executing it — especially if there’s any personnel change — may not share that understanding. Nobody thinks to brief them on assumptions that were never written down, because nobody remembers those assumptions existed.
When Assumptions Become Risks
I mentioned this earlier and want to come back to it, because the relationship between assumptions and the risk register is consistently underused.
Every assumption carries embedded risk. The mechanism: an assumption is a belief held as true; a risk is a potential event that could affect the project. If an assumption turns out to be false, the project experiences an impact. Which means the assumption was, from the start, a risk in disguise — one that didn’t make it into the risk register because it was filed under “assumptions” instead.
When you document an assumption, the immediate next question should be: what happens if this assumption is wrong? That question produces a risk. The assumption that regulatory approval will take four to six weeks produces the risk that approval takes longer and delays the launch. The assumption that the client has internal resources available for testing produces the risk that those resources aren’t available when needed.
Not every assumption needs a formal risk entry. Some have high probability of being correct and low impact if wrong — monitoring passively is fine. Others need active validation and contingency planning. The prioritization logic is the same as any risk: probability times impact determines how much attention it deserves.
One mistake I’ve seen repeatedly: teams document assumptions at initiation and never touch them again. As the project progresses, some get confirmed, some turn out to be false, and new ones emerge. An assumption log reflecting the state of the project at month one is not useful at month six — and the false ones that nobody updated are quietly doing damage.
Managing Assumptions and Constraints Through Execution
The assumption log is only useful as a living document. At minimum, review it at each phase gate or major milestone: which assumptions have been validated, which have been invalidated, which are still pending.
For each assumption there should be an owner, a validation method, and a due date. Without those fields, the log is a list of beliefs with no mechanism for converting them into knowledge. Owner tells you who’s watching it. Validation method tells you how you’ll know if the assumption holds. Due date tells you when it needs to be confirmed before it starts affecting planning decisions downstream.
Constraints work differently. Because they’re fixed, the management task is enforcement, not verification. When scope changes come in, cost increases emerge, or schedule adjustments are requested, the first check is always: does this violate an existing constraint? If it does, the change either needs rejection or a formal constraint change process — not quiet absorption into the plan.
The connection between constraints and change control is often the weakest link in project governance. Projects with fixed budget constraints still approve cost-increasing changes — incrementally, each one seemingly minor, until the cumulative effect has effectively moved the constraint without anyone having made that decision explicitly. By the time the total impact is visible, the conversation about whether the constraint should have changed has already been bypassed.
Real-World Assumptions and Constraints Examples
Software development project
A financial services firm building a new client portal. Assumptions: the authentication system can integrate with the existing identity provider; the security review team has capacity for one round of review in month three; UAT will take two weeks with ten users. Constraints: all data must remain in-country per regulatory requirements; the project budget is fixed at $780,000; the portal must go live before a contractual client deadline in Q4.
If the authentication assumption fails — it can’t integrate without significant rework — that’s a materialized risk requiring a scope or schedule response. If the data residency constraint is violated, that’s a compliance failure. Same project, very different types of problem, very different responses required.
Construction project
Municipal infrastructure. Assumptions: soil conditions match the desk study; utility relocation completes on the contractor’s schedule; no significant archaeological findings surface. Constraints: the road must remain open to emergency vehicles at all times; practical completion must precede winter weather that would make certain activities impractical; environmental permits restrict work hours near the watercourse.
On this type of project, assumption failures cascade. A soil condition failure forces redesign, which pushes schedule, which may then conflict with the seasonal constraint. Knowing which items are assumptions — manageable if monitored early — and which are constraints — fixed — determines which problems can be worked around and which require immediate escalation to the client.
The one that was documented but still went wrong
A system implementation project. The team assumed the client’s data governance team would sign off on the migration approach within the first month — documented, marked low risk, based on informal conversations during the sales process. Nobody formally confirmed it. The data governance team had been developing a new data classification policy that would require additional controls for this data type. Their sign-off took fourteen weeks, not four. Significant rework to the migration approach followed. The project was late and over budget.
The assumption log wasn’t wrong. The risk assessment attached to it was. “Low risk” was assigned because everyone thought it was a formality. Nobody asked whether the governance team had any ongoing workstreams that might affect their timeline. The lesson isn’t that you need to document more assumptions — it’s that the risk assessment quality on each assumption matters as much as whether the assumption gets documented at all.
Wanda is the Director of Blue Horizons Professional Training Services which focuses on the delivery of PMI-SP, Stakeholder Management and other project related workshops, training, mentoring and consulting services. She holds a Doctor of Project Management from Harward University.
