Project assumptions are the facts a plan quietly depends on, and like milk in the fridge, they have an expiry date. A supplier promised four-week delivery, a key developer was available full time, the budget was approved at a certain exchange rate. All of it was true on the day the plan was written. Months later the plan still says the same thing, but the world has moved on. That gap is the assumption expiry problem, and it sinks more projects than most teams like to admit.
This guide explains why assumptions go stale, how to spot the warning signs and how to build a simple habit that keeps your plans honest. If you want structured skills for it, our project management courses cover planning, risk and delivery in practical detail.
Illustrative example only.
What Is Project Assumption Expiry?
An assumption is something you treat as true for planning purposes without having proved it. Expiry happens when that statement stops being accurate, but nobody updates the plan. The schedule, budget and risk register keep running on information that is no longer valid.
The danger is that stale project assumptions don’t announce themselves. They don’t raise alerts or flip a status to red. They just sit inside estimates and dependencies until a milestone slips and someone asks, ‘Wait, when did that change?’
Why Project Assumptions Go Stale
Plans are written once and reviewed rarely
Most teams invest heavily in the initial plan, then update the dates and percentages but not the reasoning behind them. The original assumptions get buried in a document nobody reopens.
Nobody owns the assumption
A risk usually has an owner and a response. An assumption often has neither. If no named person is responsible for checking it, nobody notices when it stops being true.
There’s no review or expiry date
Few logs record when an assumption was last validated or when it should be checked again. Without that, a six-month-old guess looks just as solid as a confirmed fact.
The external world keeps changing
Prices move, regulations shift, vendors change terms, people resign and technology versions reach end of life. Project assumptions about any of these can age quickly, especially on long projects.
Handovers lose the context
When a project manager or team member changes, the reasoning behind early decisions often leaves with them. The new person inherits the numbers but not the conditions they were based on.
Optimism and anchoring
Once a stakeholder has been told ‘six weeks’, revisiting that figure feels like admitting failure. Teams cling to old project assumptions because changing them is socially uncomfortable.
Examples of Expired Project Assumptions
- Supplier lead times: the four-week delivery quoted at kickoff is now eight weeks, but the schedule hasn’t changed.
- Resource availability: a specialist promised at 80 percent is now split across three projects.
- Budget and pricing: costs were estimated before a price rise, a contract renewal or a currency movement.
- Regulatory or approval timing: a permit that was expected in three weeks is stuck in a longer queue.
- Technology versions: the plan assumes a platform feature that has since been changed or retired.
- Customer demand: the business case relies on usage numbers from last year’s market.
Warning Signs That Your Project Assumptions Are Out of Date
- Nobody can say who confirmed key assumptions or when.
- The assumption log, if it exists, hasn’t been edited since planning.
- Estimates are unchanged even though scope, team or conditions have changed.
- Team members use phrases like ‘I thought that was already sorted’.
- Dependencies keep slipping with surprise explanations.
- Stakeholders question numbers that were once accepted without debate.
If three or more of these sound familiar, it’s worth pausing for a short assumption review before the next milestone.
The Real Cost of Unchecked Project Assumptions
- Schedule slippage: dependencies that no longer hold cause delays further down the line.
- Budget overruns: old cost inputs create a gap between forecast and reality.
- Rework: work built on a false premise has to be redone.
- Lost credibility: repeated surprises reduce stakeholder trust in the project manager and the plan.
- Poor decisions: leaders choose between options using outdated information.
How to Manage Project Assumptions in Seven Steps
- Capture every assumption explicitly. Run a short workshop during planning and write them in plain language, for example ‘The vendor will deliver within four weeks of order’.
- Assign an owner to each one. One named person checks it, not ‘the team’.
- Record the source and the date. Note where the information came from and when it was last confirmed.
- Add a review date or trigger. Decide when it must be revalidated, such as monthly, at each stage gate or when a related event occurs.
- Link it to impact. State what changes in the schedule, budget or scope if the assumption proves wrong.
- Review in regular meetings. Make a two-minute assumption check part of your usual status or sprint review.
- Convert or retire. When an assumption is confirmed it becomes a fact, and when it fails it becomes a risk or an issue with a response plan.
What to Include in a Project Assumptions Log
A good log is short and easy to maintain. At a minimum, include these fields:
- A unique ID and a clear statement of the assumption
- The owner responsible for validating it
- Source of the information and date it was last confirmed
- Next review date or trigger event
- Impact if it turns out to be false
- Status: valid, needs checking, invalid or closed
Many teams combine this with a risk, assumption, issue and dependency (RAID) log, which keeps related items visible in one place.
How Different Methods Handle Project Assumptions
Whatever methodology you use, the principle is the same: surface the assumption, test it and keep checking. Structured methods such as PRINCE2 give assumptions a home in planning and logging. Agile approaches reduce the damage by working in short cycles, so a false assumption is discovered after weeks rather than months. You can learn more about project management standards from bodies such as the Project Management Institute and the Australian Institute of Project Management.
If your teams deliver iteratively, the Agile Business Consortium is a useful reference, and our AgilePM Foundation and AgilePM Practitioner courses show how to build assumption checks into iterative delivery.
Project Assumptions in Australian Projects
Long infrastructure, government, resources and technology projects are especially exposed because conditions change over years, not weeks. Whether your team is in Sydney, Melbourne, Brisbane, Perth, Adelaide or Canberra, regular assumption reviews are a low-cost safeguard. Teams in Hobart and across New Zealand can also join live online training. See all options on our locations page.
Learn Assumption and Risk Management With Expert Tutors
Good habits come easier with a shared method. Our courses are available online, live virtual or in-house, with full-time weekday, part-time weeknight and part-time weekend options. Browse the full course list, or compare the wider project management courses, business analysis training and the project management job program.
To learn more about who we are, visit the about us page, or check the FAQs for answers to common course questions.
Project Assumptions FAQs
What are project assumptions?
They are statements you treat as true for planning without having confirmed them, such as resource availability, delivery times or approval dates. They’re recorded so the team can test them as the project progresses.
What is the difference between an assumption and a risk?
An assumption is something you’re relying on being true. A risk is an uncertain event that could affect objectives. A false assumption can become a risk or an issue, which is why they’re often tracked together.
How often should I review project assumptions?
At least at each stage gate or monthly, and immediately when a related change occurs. Fast-moving projects may check them every sprint or weekly.
Who should own project assumptions?
The project manager owns the process, but each assumption should have a named individual who verifies it, ideally the person closest to the information.
Where can I read more project management guides?
Our blog shares regular guides on planning, risk and delivery.
Check Your Facts Before They Check You
No plan stays accurate on its own. The projects that cope best aren’t those with perfect forecasts, but those that regularly ask whether yesterday’s facts are still true. Make project assumptions visible, owned and dated, and you’ll catch most expiry problems while they’re still cheap to fix.
Want your team to plan with more confidence? Contact us to discuss training, or start with the course catalogue.