A project plan is full of statements that look like facts before they have earned that status.
The supplier will deliver in six weeks. The regulator will use the expected review route. The existing data is clean enough to migrate. The team can reuse the current platform. User demand will remain near the forecast. The specialist will still be available in November. The new process will reduce workload rather than move it somewhere else.
Some of those statements will prove true. Some will not. The project still has to plan before all of them can be demonstrated.
Project assumption management is the discipline of identifying what a project is treating as true without complete proof, understanding what depends on those beliefs, assigning ownership, testing them as evidence improves and changing the project before a failed assumption becomes an avoidable surprise.
An assumption is therefore not simply a note in a planning document. It is a temporary bridge across missing knowledge.
Professional project management does not pretend those bridges are permanent. It labels them, inspects them and replaces them with evidence as soon as the project can.
The one-sentence answer
Project assumption management works by identifying propositions the project currently needs to treat as true, recording their rationale and consequence, separating them from facts and constraints, linking them to estimates, requirements, risks and decisions, defining how and when they will be validated, and changing the plan when evidence confirms, weakens or invalidates them.
1. What is a project assumption?
The Project Management Institute’s current Lexicon of Project Management Terms defines an assumption as a factor in planning that is considered true, real or certain without proof or demonstration. The same lexicon defines the assumption log as a project document used to record assumptions and constraints throughout the project. Source: Project Management Institute, Lexicon of Project Management Terms, Version 5.0.
That definition explains the management problem precisely.
An assumption is useful because the project cannot wait for complete certainty before doing anything. But the same assumption is dangerous if the project forgets that proof was missing when the assumption entered the plan.
The goal is not to eliminate assumptions. The goal is to stop assumptions from disguising themselves as facts.
2. Why projects need assumptions
Projects are decisions made under incomplete information.
A team may need to estimate cost before design is complete. It may need to reserve resources before every dependency is confirmed. It may need to select a delivery approach before user behaviour is fully observed. It may need to plan procurement before every supplier condition is known.
Waiting for perfect knowledge can itself destroy value because decisions have windows.
Assumptions allow provisional planning to continue. They become professional when the project remembers that the provisional state exists.
3. Assumption vs fact
A fact is supported by evidence appropriate to the claim. An assumption is accepted temporarily despite incomplete proof.
“The supplier confirmed in writing that the current lead time is six weeks” is evidence about the supplier’s stated lead time.
“The supplier will deliver our order exactly six weeks after award” is still an assumption until the future event occurs, even if the assumption is well supported.
Evidence can strengthen an assumption without transforming a future proposition into a present fact.
This distinction prevents a common failure: a credible source being treated as proof that the future must behave exactly as expected.
4. Assumption vs constraint
An assumption is something the project is treating as true. A constraint limits the solution or delivery system.
Examples of constraints include:
- a fixed regulatory deadline;
- an authorised budget ceiling;
- a mandated technology standard;
- a site-access window;
- a contractual interface;
- a legal or policy requirement.
The distinction matters because a constraint may itself be based on an assumption.
For example, leadership may impose a 1 December launch date because it assumes the market opportunity disappears after that date. The date is a constraint. The commercial belief behind it is an assumption.
If the assumption is wrong, the constraint may deserve reconsideration. If the project records only the date and loses the reasoning, that option disappears from view.
5. Assumption vs risk
An assumption and a risk are related but different.
Assumption:
The external reviewer will be available during the planned review week.
Risk arising from the assumption:
If the reviewer is unavailable, approval may move beyond the release window and delay publication.
The assumption describes what the plan currently treats as true. The risk describes uncertainty and consequence if reality differs.
PMI material has long treated the assumption log as an input into risk work because assumptions can give rise to project risks. Source: Project Management Institute, PMBOK Guide Sixth Edition material.
Project Risk Management owns future uncertainty. Assumption management owns the propositions on which parts of the project model currently depend.
6. Assumption vs dependency
A dependency describes what one activity or deliverable needs from another. An assumption describes what the project believes about that dependency or its environment.
Dependency:
System testing requires the supplier component to be accepted before integration begins.
Assumption:
The supplier component will reach acceptance by 8 October.
When the assumed date becomes uncertain or changes, Project Dependency Management shows the receiving consequence. Assumption management explains which belief inside the plan must now be re-examined.
7. Assumption vs issue
An assumption is not an issue merely because it is uncertain.
If the project assumes a specialist will remain available and the specialist resigns, the assumption has failed and an issue now exists.
The project should preserve the connection:
Assumption A-14 invalidated → resource issue I-27 opened → schedule and estimate reassessed.
Project Issue Management owns the active problem once the event has happened.
8. Assumption vs requirement
A requirement states a condition the project has committed to satisfy. An assumption states a condition the project currently believes will be true.
The distinction becomes important when a requirement is derived from an assumption.
Suppose the team assumes users will access the service only from modern smartphones. That belief may influence interface, browser and accessibility requirements.
If user research later shows substantial desktop use, several derived requirements may need revision.
Project Requirements Management owns the requirement lifecycle. Assumption management preserves the belief that generated or shaped those requirements.
9. Assumption vs estimate
Estimates are built on assumptions.
An effort estimate may assume a certain productivity rate. A duration estimate may assume a specialist remains available. A cost estimate may assume inflation, labour rates, exchange rates, quantities or supplier behaviour.
The U.S. Government Accountability Office’s Cost Estimating and Assessment Guide treats ground rules and assumptions as a formal step in reliable cost estimating. It emphasises that assumptions should be realistic, supported where possible by historical data, gathered in a form that allows sensitivity and risk analysis, and revisited as more information becomes known. Source: U.S. GAO, Cost Estimating and Assessment Guide.
Project Estimation owns the prediction model. Assumption management owns the beliefs that make the prediction possible.
10. The assumption log
An assumption log is useful when it helps the project act differently because an assumption exists.
A weak log is a list created during initiation and never revisited.
A stronger assumption log records enough information to test consequence and validity.
| Field | Purpose |
|---|---|
| Assumption ID | Stable identity for references and history. |
| Statement | What the project is currently treating as true. |
| Rationale | Why the assumption is considered reasonable. |
| Evidence | Information supporting or weakening it. |
| Owner | Who is responsible for maintaining its state. |
| Dependent decisions / plans | What changes if the assumption fails. |
| Confidence | How strong the current evidence is. |
| Validation method | How the assumption can be tested or replaced by evidence. |
| Review / expiry point | When the assumption must be reconsidered. |
| Linked risks | Uncertainty created by possible invalidity. |
| Status | Proposed, active, validated, invalidated, superseded or retired. |
The exact fields should be tailored. The principle is simple: an assumption deserves enough metadata to prevent it from disappearing into narrative prose.
11. Write assumptions as testable propositions
“Users are comfortable with technology” is a poor project assumption because it is vague.
A stronger statement might be:
At least the large majority of intended users can complete the new booking workflow on their existing device without staff assistance after the planned onboarding.
The exact threshold should come from the project’s real need. The improvement is that the statement now points toward evidence.
Useful assumption statements identify:
- the condition;
- the relevant population, system or environment;
- the time period;
- the project decision that depends on it where useful.
If an assumption cannot be stated clearly enough to test, the project may not understand what it is assuming.
12. Record the rationale, not only the statement
An assumption becomes more useful when the project records why it considered the assumption reasonable.
Possible rationale includes:
- historical performance;
- supplier quotation;
- expert judgement;
- market data;
- prototype results;
- policy precedent;
- user research;
- contractual indication;
- technical analysis.
The rationale lets a future reviewer distinguish a well-founded working assumption from an unexamined convenience.
GAO guidance makes this point strongly in estimating: important assumptions should be realistic, valid, documented and supported by historical data or expert judgement rather than being arbitrary. Source: U.S. GAO, Cost Estimating and Assessment Guide, Step 5.
13. Give each consequential assumption an owner
An owner is responsible for maintaining the assumption’s status and driving validation or escalation.
The owner does not need to control the underlying reality.
A procurement lead cannot force a supplier’s factory to remain on schedule. The lead can own the assumption that the quoted lead time remains credible, collect evidence, identify warning signs and escalate when confidence falls.
Ownership turns the assumption from passive documentation into a managed condition.
14. Confidence should be explicit
Not all assumptions are equally uncertain.
One may be supported by several years of stable historical data. Another may depend on one stakeholder’s expectation. A third may concern technology nobody on the team has deployed before.
A simple confidence description can help:
- High: substantial current evidence; low uncertainty remains.
- Medium: plausible evidence exists, but meaningful uncertainty remains.
- Low: the project is relying on weak, indirect or immature evidence.
The labels are useful only if the project defines what they mean in context. A numeric score can be used instead, but mathematics should not disguise weak evidence.
15. Consequence matters as much as confidence
A low-confidence assumption may require little attention if nothing important depends on it.
A medium-confidence assumption may require immediate investigation if it controls a contract award, a safety decision or the critical path.
A useful review therefore considers two dimensions:
- How uncertain is the assumption?
- What happens if it is wrong?
This helps the project focus validation effort where uncertainty and consequence combine.
16. Map what depends on the assumption
Some assumptions sit quietly beneath several project controls.
Assume that an existing platform can support 10,000 concurrent users.
That one belief may affect:
- architecture;
- hosting cost;
- procurement scope;
- performance requirements;
- load testing;
- launch sequence;
- operational resilience.
If the assumption fails late, the consequence is larger because several decisions have already been built on top of it.
Assumption management should therefore identify important downstream commitments, not merely record the belief itself.
17. Assumption chains
Assumptions often depend on other assumptions.
For example:
Users will adopt the new process → because training will be sufficient → because managers will release staff for training → because operational workload will remain near forecast.
The final benefit may appear to depend on one adoption assumption when it actually depends on a chain of beliefs.
Tracing those chains is valuable because it shows where evidence has the highest leverage.
If operational workload is already rising sharply, the project may need to revise the training plan before the adoption assumption fails.
18. Hidden assumptions are more dangerous than explicit assumptions
The most dangerous assumption is often the one nobody realises the plan contains.
A schedule may assume approvals occur immediately after submission because no explicit review duration was modelled.
A cost estimate may assume internal staff time is free because it does not appear in the external budget.
A requirements document may assume “user” means one specific group while another group is also affected.
A benefit model may assume adoption reaches a target without modelling the organisational change needed to achieve it.
Assumption discovery therefore requires reading plans for what they silently presume, not only collecting statements labelled “assumption.”
19. Ask the inverse question
One practical discovery technique is to ask:
What must be true for this plan to work?
Then ask:
Which of those conditions have we actually demonstrated?
The gap between the two answers is an assumption-discovery field.
This works particularly well for:
- business cases;
- critical milestones;
- supplier plans;
- resource plans;
- benefit maps;
- technical architecture;
- operational handover.
20. Use pre-mortems to reveal assumptions
A pre-mortem asks the team to imagine the project has failed and identify plausible reasons.
This often exposes hidden assumptions because people begin naming conditions the plan had quietly taken for granted.
“We assumed the data was cleaner.”
“We assumed the supplier could scale.”
“We assumed managers would release staff for training.”
“We assumed the old system could run in parallel for three months.”
These statements can then become explicit assumptions, risks or validation tasks.
21. Assumption review during estimation
Every estimate review should include an assumption review.
The newly published Project Estimation guide explains how effort, duration and cost estimates depend on assumptions about scope, productivity, resources, rates and risk.
GAO guidance goes further by recommending that assumptions be gathered, tested through sensitivity or risk analysis where appropriate, and updated as actual information becomes available. Source: U.S. GAO, Cost Estimating and Assessment Guide.
A useful estimating review asks:
- Which assumptions move the estimate most?
- Which are supported by historical data?
- Which depend mainly on expert judgement?
- Which can be tested before commitment?
- What happens if a key assumption changes?
22. Sensitivity analysis finds important assumptions
Not every assumption deserves equal attention.
Sensitivity analysis tests how much an output changes when an input assumption changes.
If a ten-percent change in labour rate barely affects the business case but a four-week change in regulatory approval destroys the delivery window, the approval assumption has higher decision leverage.
This helps the project direct research and contingency toward assumptions that control important outcomes.
GAO’s cost-estimating guidance explicitly connects assumptions with sensitivity and risk analysis because changes to important assumptions can invalidate major parts of an estimate. Source: U.S. GAO, Cost Estimating and Assessment Guide.
23. Validation should be designed, not hoped for
An assumption should have a plausible route to stronger evidence whenever the consequence justifies it.
Examples:
- Assumption: users can complete the new workflow without support. Validation: representative usability test.
- Assumption: legacy data can be migrated with low manual correction. Validation: profile and migrate a representative sample.
- Assumption: supplier lead time is six weeks. Validation: obtain committed production slot and monitor intermediate evidence.
- Assumption: current infrastructure supports expected load. Validation: performance test under representative conditions.
- Assumption: staff can absorb the new operating process. Validation: pilot and measure workload.
The validation activity should be proportionate to the cost of being wrong.
24. Replace assumptions before irreversible commitment
The best time to test a major assumption is usually before the project passes through the decision that makes failure expensive.
Test user demand before ordering capacity that cannot be repurposed.
Test soil conditions before finalising foundations.
Test migration quality before committing to a one-way cutover.
Test interface compatibility before awarding dependent packages where possible.
This connects assumption management to Project Decision Management. The lower the reversibility of the upcoming choice, the stronger the case for converting important assumptions into evidence first.
25. Assumptions need review dates and expiry conditions
An assumption can be reasonable in March and dangerous in September.
Supplier capacity changes. Market conditions move. staff leave. regulations evolve. exchange rates change. technology matures. customer behaviour shifts.
Important assumptions should therefore have a review point or expiry condition.
Examples:
- review after prototype results;
- review before contract award;
- review when supplier quote expires;
- review before baseline approval;
- review when utilisation exceeds a threshold;
- review when regulation or policy changes.
An assumption without a review route tends to become institutional folklore.
26. Triggers turn observation into action
A trigger is an observable condition that causes the project to reconsider an assumption or activate a response.
For example:
Assumption: supplier delivery remains inside the six-week planning assumption.
Trigger: production slot is not confirmed by the end of Week 1.
Response: activate alternate-supplier assessment before the latest useful sourcing decision date.
This is stronger than writing “monitor supplier closely.”
27. Assumption invalidation should propagate through the project
When an important assumption fails, changing the assumption log is not enough.
The project should ask what else depends on that belief.
- Does the estimate change?
- Does the schedule change?
- Does the requirement set change?
- Does the risk profile change?
- Does a supplier instruction change?
- Does the business case change?
- Does a previous decision need reopening?
- Does an issue need to be created?
Project Integration Management owns the whole-system consequence. Assumption management provides the reason the propagation started.
28. Validate, invalidate, supersede or retire
An assumption does not remain “open” forever.
Useful end states include:
- Validated: sufficient evidence supports the condition for the project purpose.
- Invalidated: evidence shows the assumption is not true.
- Superseded: a newer assumption or decision replaces it.
- Retired: the project no longer depends on the assumption.
Validation should be scoped. Evidence that a condition held during a pilot does not necessarily prove it will remain true at full scale.
A status should always mean something specific enough that downstream users understand what confidence it provides.
29. Assumption debt
Assumption debt accumulates when a project keeps building on untested beliefs while postponing validation.
At first the cost may appear small.
The team assumes data quality is sufficient. Design continues. interfaces are built. migration scripts are written. training is scheduled.
Months later, profiling reveals extensive data inconsistency.
The original uncertainty did not become larger because time passed. The consequence became larger because more work depended on the assumption.
Assumption debt is therefore the accumulated exposure created by delaying evidence while dependency on the assumption grows.
30. A worked example: data migration
Consider a fictional project migrating customer records from a legacy system.
The initial plan contains this assumption:
A-07 — Existing customer records are sufficiently complete and internally consistent that no more than a small minority will require manual correction before migration.
The rationale is weak but plausible: the legacy system has run for several years and operational teams report few visible problems.
Several plans depend on A-07:
- migration effort is estimated at four weeks;
- only two temporary data-quality analysts are budgeted;
- training begins one week after migration;
- legacy-system retirement is scheduled soon after cutover.
The project labels confidence as medium and identifies a validation activity: profile a representative data sample before detailed migration build.
The profiling finds that 18 percent of records contain at least one material inconsistency requiring rule development or manual intervention.
A-07 is invalidated.
The project then:
- opens an issue for current data-quality remediation;
- re-estimates effort and duration;
- adds data-cleansing requirements;
- revises resource demand;
- reassesses the training and legacy-retirement dependencies;
- routes any resulting baseline changes through change control.
The validation did not create the problem. It discovered the problem while options still existed.
31. A worked assumption log
| ID | Assumption | Confidence | Key dependency | Validation | Status |
|---|---|---|---|---|---|
| A-07 | Legacy data requires only limited manual correction. | Medium | Migration effort and cutover date. | Representative data profile. | Invalidated |
| A-08 | Current hosting can support expected launch load. | Low | Architecture and hosting budget. | Load test before architecture freeze. | Active |
| A-09 | External reviewer remains available in November. | Medium | Acceptance review. | Written booking confirmation six weeks before review. | Active |
| A-10 | Managers can release staff for two training sessions. | Low | Adoption plan and benefits. | Operational capacity check with managers. | Active |
| A-11 | Existing API remains supported through transition. | High | Integration design. | Vendor roadmap and contract confirmation. | Validated for current release window |
This is an illustrative teaching log. Real projects should choose fields and validation strength according to consequence, regulation and organisational practice.
32. Assumptions in the business case
Business cases can be highly sensitive to assumptions about demand, adoption, cost, productivity, savings and timing.
A benefit case may assume:
- 80 percent user adoption;
- a certain transaction volume;
- staff time saved per transaction;
- no material increase in support demand;
- benefits begin immediately after launch.
If those assumptions are invisible, benefit forecasts can appear more certain than the evidence justifies.
Project Benefits Realisation should preserve the assumptions connecting outputs to outcomes so post-project reviews can test whether the causal model held.
33. Assumptions in schedule management
Schedules contain many assumptions that are not visible as logical links.
- resource productivity;
- approval duration;
- weather conditions;
- supplier lead times;
- calendar availability;
- rework levels;
- access windows;
- regulatory review behaviour.
Project Schedule Management becomes more credible when the assumptions behind durations and constraints are visible enough to test.
PMI material notes that assumptions and constraints in the assumption log can influence sequencing and may give rise to project risks affecting the schedule. Source: PMI PMBOK Guide Sixth Edition material.
34. Assumptions in procurement
Commercial decisions often depend on assumptions about the market, suppliers and client responsibilities.
The project may assume:
- three capable suppliers will bid;
- the market has sufficient capacity;
- the selected supplier can recruit locally;
- client-furnished information will be available on time;
- raw-material pricing remains inside a planning range.
Those beliefs affect package strategy, contingency and negotiation leverage.
Project Procurement Management should therefore distinguish supplier facts from market assumptions before contract structure hardens around them.
35. Assumptions in stakeholder management
Stakeholder plans can contain assumptions about influence, resistance, communication preference and decision authority.
“Users support the change” may reflect one workshop attended by a small subset.
“The sponsor will resolve the policy dispute” may be an assumption about authority rather than a verified governance fact.
Important stakeholder assumptions should be tested through Project Stakeholder Management, especially where adoption or legitimacy controls benefits.
36. Assumptions in quality and acceptance
Teams sometimes assume that acceptance criteria will be interpreted the same way by everyone.
They may assume a prototype proves production readiness, a test environment represents real load, or a supplier certificate is sufficient evidence for final acceptance.
These assumptions should be challenged before final verification.
Project Quality Management defines the evidence and acceptance system. Assumption management asks what that system quietly presumes about representativeness, thresholds and authority.
37. Assumptions in agile projects
Agile methods do not eliminate assumptions. They can make it cheaper to test some of them.
A backlog item may embody an assumption about user value. A prototype may test that assumption. A sprint may test a technical assumption. A release may test adoption at a larger scale.
The adaptive advantage comes from shortening the time between assumption and evidence.
But teams should not interpret frequent delivery as proof that every business assumption is validated. Shipping a feature confirms that the team can ship it. It does not automatically confirm that the feature creates value.
Agile Project Management is strongest when experiments are designed around important assumptions rather than activity alone.
38. Assumptions in hybrid projects
Hybrid projects contain assumptions at multiple control speeds.
A programme-level contract may assume a fixed completion date. An agile product team may assume a feature hypothesis can be tested in two iterations. A physical installation may assume the interface specification remains stable after design freeze.
The project should know which assumptions can be explored adaptively and which must be validated before predictive commitments become difficult to reverse.
Hybrid Project Management provides the boundary between those control modes.
39. Assumptions in programmes
Programme assumptions can sit above several projects.
A programme may assume all component projects can transition into one target operating model. It may assume benefits emerge once several capabilities coexist. It may assume organisational capacity can absorb multiple changes within one period.
These assumptions cannot be owned entirely by one component project because their consequence crosses project boundaries.
Programme Management should maintain programme-level assumptions and link them to the components they influence.
40. Assumptions in portfolios
Portfolio choices also depend on assumptions.
An organisation may assume growth continues, a regulation takes effect, a capability remains scarce, a technology becomes viable or a competitor behaves in a certain way.
These beliefs affect which projects are started, stopped or accelerated.
Portfolio Management should revisit strategic assumptions when external conditions change rather than protecting the investment list from new evidence.
41. Assumptions in megaprojects
Megaprojects amplify assumption consequence because decisions are large, long-lived and difficult to reverse.
Demand forecasts, land availability, political continuity, technology maturity, construction productivity, inflation, financing, regulatory timing and operational behaviour can all become major assumptions.
The longer the horizon, the more likely some assumptions will expire before the project ends.
Megaproject Management therefore benefits from scenario analysis, reference classes, staged commitments and independent challenge of key assumptions.
42. Assumption management during project recovery
Troubled projects often fail because the plan still contains assumptions that reality has already disproved.
The supplier will catch up. The team can recover through overtime. The unresolved defect is isolated. Users will accept the workaround. Additional funding will arrive. The date remains achievable.
Project Recovery should therefore reconstruct the assumption set from current evidence.
A recovery baseline built on the same invalid assumptions that damaged the original baseline is not recovery. It is repetition with a new date.
43. Assumptions and project assurance
Independent assurance should challenge important assumptions before major commitments.
An assurance review can ask:
- Which assumptions control the business case?
- Which assumptions control the critical path?
- Which assumptions remain low confidence?
- What evidence would invalidate them?
- Has the project tested the highest-consequence beliefs?
- Do independent data or reference classes contradict them?
Project Assurance is particularly valuable where project teams are invested in assumptions they helped create.
44. Assumptions and AI
AI can help expose assumptions because it can scan plans, requirements, estimates, meeting records and risks for propositions that appear to be treated as true without explicit evidence.
It can also invent assumptions or present inference as fact.
A strong AI-assisted workflow separates machine suggestions from authorised project state:
- AI identifies candidate hidden assumptions;
- owners confirm whether the project actually relies on them;
- source evidence is attached where available;
- confidence and consequence are assessed;
- validation tasks are assigned;
- only verified project records update official state.
AI Project Management owns the wider rule: AI can accelerate sense-making, but it does not automatically create evidence, authority or truth.
45. Common failure: assumptions are written once and forgotten
The charter contains an assumption log. Six months later nobody knows whether the assumptions are still current.
Fix this by attaching review points to consequential assumptions and including them in relevant planning, risk and decision reviews.
46. Common failure: assumptions are too vague to test
“Stakeholders are supportive.” “The system is scalable.” “Training will be sufficient.”
These statements sound plausible but do not define what evidence would confirm or weaken them.
Rewrite them as specific propositions tied to project consequence.
47. Common failure: optimistic assumptions are treated as normal assumptions
Some assumptions are chosen because the project needs them to be true.
“Approval will take two weeks because otherwise the date does not work” is not evidence.
The plan should distinguish what must be true from what evidence suggests will be true.
48. Common failure: assumptions hide inside baselines
Once a schedule or budget is approved, people begin treating every input inside it as equally firm.
Approval does not transform uncertain assumptions into facts.
A mature baseline can contain controlled uncertainty as long as the assumptions and ranges remain visible.
49. Common failure: failed assumptions become blame
An assumption can be reasonable and still prove false.
The learning question is whether the assumption was proportionately evidenced, whether consequence was understood, whether validation occurred at the right time and whether warning signals were acted upon.
Blaming people simply because uncertainty resolved unfavourably discourages transparent assumptions and encourages hidden certainty.
50. Common failure: no link between assumption and decision
The project records dozens of assumptions but cannot identify what would change if any of them failed.
If an assumption has no meaningful project consequence, it may not need formal management. If it has consequence, connect it to the decision, estimate, requirement, dependency, risk or benefit it influences.
51. Common failure: everything uncertain is called an assumption
Some unknowns are questions, not assumptions.
“We do not know whether Regulation X applies” should remain an unresolved question until the project chooses a temporary planning assumption deliberately.
This distinction matters because silently converting unknowns into assumptions can bypass needed research or legal advice.
52. Common failure: validated once means true forever
Evidence has a scope and time boundary.
A supplier capacity confirmation from six months ago may no longer be current. A pilot with 100 users may not validate behaviour at 100,000 users. A demand forecast before a major market change may need refresh.
Validated assumptions should carry the context in which validation applies.
53. Common failure: assumption logs become risk-register duplicates
If every assumption is rewritten as “risk that assumption is wrong,” the project loses the distinction between the planning proposition and the uncertain event.
Keep the relationship explicit:
Assumption → dependency on assumption → risk if invalid → trigger → response.
This structure preserves both planning logic and uncertainty management.
54. A practical assumption-management cycle
- Discover: ask what must be true for the plan, estimate, requirement, decision or benefit model to work.
- State: write the assumption clearly enough to test.
- Source: record why the assumption is considered reasonable.
- Own: assign responsibility for maintaining its status.
- Assess: judge confidence and consequence if wrong.
- Trace: identify decisions, requirements, estimates, dependencies, risks and benefits that rely on it.
- Validate: define the evidence that could strengthen or invalidate it.
- Time: assign review points, expiry dates or triggers.
- Act: change the project when evidence changes the assumption state.
- Propagate: update affected controls rather than changing the log alone.
- Close: validate, invalidate, supersede or retire the assumption explicitly.
- Learn: compare which assumptions failed and why so future planning improves.
This is a practical teaching cycle rather than a mandatory industry process. The degree of formality should match project consequence and complexity.
55. A practical assumption review
- What is the project currently treating as true without full proof?
- Why is that belief considered reasonable?
- How strong is the supporting evidence?
- What depends on the assumption?
- What happens if it is wrong?
- Who owns the assumption?
- Can we test it before an irreversible decision?
- What evidence would validate or invalidate it?
- When must it be reviewed?
- What observable trigger should cause action?
- Which risk describes the consequence of failure?
- Which estimate, requirement, dependency or benefit model would need update?
- Is this actually an assumption, or is it a fact, constraint, question, risk or issue?
- Has the assumption become stale because the environment changed?
56. The deeper idea
Project assumption management is the discipline of remembering where knowledge ends and planning begins.
Every serious project must act before the future is fully known. The mistake is not making assumptions. The mistake is forgetting which parts of the project were built on them.
A mature project keeps those temporary beliefs visible. It knows which assumptions matter, which decisions depend on them, what evidence could replace them and when delay in validation becomes more dangerous than uncertainty itself.
The strongest assumption log is therefore not the longest list. It is the map that lets the project answer a harder question: Which parts of our plan are still beliefs, and what are we doing before those beliefs become commitments we can no longer easily reverse?
Sources and boundaries
The core definition of assumption and assumption log in this article was checked against the Project Management Institute’s current 2026 Lexicon of Project Management Terms. The relationship between assumptions, estimating, risk and sensitivity analysis was checked against current public U.S. GAO cost-estimating guidance and PMI project-management material in September 2026. The worked examples, lifecycle states, review questions and assumption-debt framing are original explanatory structures and should be tailored to the project’s actual governance, technical discipline, contracts, safety obligations and regulatory environment.
- Project Management Institute — Lexicon of Project Management Terms, Version 5.0. Current definitions for assumption, assumption log, baseline and related project-management terminology.
- Project Management Institute — PMBOK Guide Sixth Edition material. Shows how assumptions and constraints can influence planning, sequencing and risk.
- U.S. Government Accountability Office — Cost Estimating and Assessment Guide. Treats ground rules and assumptions as a formal estimating step and connects them to risk, sensitivity analysis, documentation and estimate updates.