The assumption gap is the distance between what a project team believes is true and what has actually been checked. It rarely announces itself. Nobody writes “we’re guessing” in the project plan. The guess just gets repeated in meetings until it sounds like a fact, and by the time it’s proven wrong, the budget has been spent and the deadline has moved.
If you’ve ever watched a well-funded project stall over something “everyone knew”, you’ve seen the assumption gap at work. This guide explains why smart teams leave assumptions unchallenged, which types do the most damage, and how business analysts close the gap before it becomes a failed project.
What Is the Assumption Gap in Projects?
Every project runs on assumptions. Users will adopt the new system. The data is clean enough to migrate. The vendor can deliver by June. The sponsor has the authority to approve the change. None of these are unreasonable on day one. The assumption gap opens when they stay unverified long after the team has started building on top of them.
Think of it as hidden debt. An untested assumption costs nothing to carry in week one. By month six, a design, a contract and a go-live date might all depend on it. Testing it then is slower, more political and far more expensive than asking the question at the start.
Here’s a simple illustration. A retailer plans a click-and-collect feature on the assumption that stores can pick orders within an hour. Nobody asks the store managers. The system is built, launched and immediately swamped, because most stores have two staff on a weekday afternoon. The technology worked perfectly. The assumption gap sank the project.
Why Nobody Challenges Assumptions (Even Smart Teams)
Teams don’t skip this on purpose. The assumption gap survives because challenging an assumption feels uncomfortable, and the project environment quietly rewards confidence over curiosity. These six reasons explain most cases.
1. Assumptions sound like facts
Once a statement has been said confidently in two meetings, it starts to feel settled. “The integration is straightforward” becomes part of the plan without anyone remembering who first said it.
2. Questioning feels like doubting the team
Asking “how do we know that?” can sound like criticism. In a room full of senior people, most will stay quiet rather than risk looking uninformed or difficult.
3. Seniority shuts down scrutiny
When a sponsor or executive states something with authority, junior team members rarely push back. The assumption gap widens fastest when the person making the assumption is the person least likely to be questioned.
4. Deadline pressure rewards moving fast
Validating assumptions takes days. Skipping it saves days. Under pressure, teams choose speed and quietly accept the risk, often without realising they’ve made a choice at all.
5. Everyone agrees, so nobody checks
Agreement feels like validation, but it’s often just shared guessing. Five people nodding doesn’t make a statement true. It only means five people hold the same untested belief.
6. There’s nowhere to record them
If assumptions aren’t written down, they can’t be reviewed. Many teams have a risk register and an issues log but no assumption log, so the most dangerous items live only in people’s heads.
Six Types of Assumptions That Quietly Sink Projects
Not every assumption carries the same weight. Sorting them by type helps you decide which ones deserve a hard look first.
| Assumption type | Example | If it’s wrong | Question to ask |
| Stakeholder | The sponsor will approve the change in time | Delays and rework | Who has actually agreed, and in writing? |
| User | Staff will happily switch to the new tool | Low adoption, wasted build | Have we spoken to the people who will use it? |
| Data | Existing data is clean enough to migrate | Blown timelines, bad reports | Who has profiled a real sample? |
| Technical | The two systems will integrate easily | Redesign mid-project | Has anyone tested this in practice? |
| Process | The documented process matches daily work | Solution fits the wrong workflow | Have we watched the work being done? |
| Business case | The benefit will arrive within a year | Funded project, missing value | What evidence supports the number? |
How the Assumption Gap Turns Into Project Failure
Unchallenged assumptions rarely cause failure directly. They flow into requirements, designs, estimates and contracts, and then surface as scope changes, rework and disappointed stakeholders. By then the cause is buried and the blame lands somewhere else.
Research supports the connection. The Project Management Institute’s 2014 Pulse of the Profession study found that 37% of organisations named inaccurate requirements as a primary reason for project failure, and that only 47% had a formal process to validate requirements. That data is a few years old, so treat it as directional rather than current, but it points to the same pattern: teams build on requirements, and therefore assumptions, that nobody confirmed.
How Business Analysts Close the Assumption Gap
This is one of the most valuable things a business analyst does. A good analyst treats every confident statement as a hypothesis worth testing, politely and early. The BABOK Guide from IIBA frames business analysis around understanding needs and validating solutions, and challenging assumptions sits right at the centre of that work. These techniques make it practical.
| Technique | When to use it | What you get |
| Assumption log | From project start, reviewed weekly | A visible list with owners and due dates |
| Assumption mapping | Early planning workshops | Assumptions ranked by impact and certainty |
| 5 Whys | When a claim sounds too convenient | The real basis behind a belief |
| Prototype or small test | For technical and user assumptions | Evidence instead of opinion |
| Data sampling | Before any migration or reporting promise | A realistic view of data quality |
| Pre-mortem | Before approval or build | A list of ways the plan could fail |
You’ll notice none of these require a big process. Most take an hour. What they require is the confidence to ask the question in the room, which is a skill that can be learned.
A 5-Step Assumption Review You Can Run This Week
- List every assumption. Run a short workshop and ask, “What are we taking for granted?” Write down every answer, however obvious it feels.
- Give each one an owner. An assumption without an owner never gets tested. Name one person responsible for each.
- Rank by impact and certainty. Focus on assumptions that are high impact and low certainty. These are where the assumption gap is widest.
- Choose the cheapest test. A conversation, a data sample, a quick prototype or a vendor confirmation in writing. Pick the fastest way to get evidence.
- Update the plan and review weekly. Mark each assumption as confirmed, disproved or still open, and adjust scope, timeline or budget accordingly.
Do this early and the assumption gap shrinks before it can grow. Do it late and you’re simply documenting the reasons the project went wrong.
The Assumption Gap Across Australian Cities
Every Australian city has its own project mix, but the underlying problem is the same everywhere. These are typical situations, not published statistics.
| City | Typical project environment | Common assumption risk |
| Sydney | Financial services and large enterprise programs | Assuming legacy systems integrate cleanly |
| Melbourne | Mixed enterprise, health and education change projects | Assuming users will adopt new processes |
| Brisbane | Government, infrastructure and resources projects | Assuming approvals and funding arrive on time |
| Perth | Resources and engineering with remote teams | Assuming site processes match the documented ones |
| Adelaide | Public sector and defence-related programs | Assuming requirements are stable across agencies |
| Canberra | Federal government transformation work | Assuming policy intent translates directly into requirements |
If you want to build these skills locally, explore our business analysis courses in Sydney, Melbourne, Brisbane, Perth, Adelaide and Canberra. Live online options make the same training available anywhere in Australia.
Build the Skills to Close the Assumption Gap
Spotting an assumption is a habit. Testing it well is a technique. Our business analysis courses teach both through hands-on exercises and real workplace scenarios, so you can practise asking the uncomfortable question before you need to do it on a live project.
Good starting points include the Business Analysis Techniques course, the AgileBA Foundation and AgileBA Practitioner courses, and the IREB Requirements Engineering Foundation (CPRE-FL). If you’re interested in the wider change picture, the BCS Business Change Foundation is worth a look. You can also browse the full course list or read more on the Business Analysis Courses blog.
Assumption Gap FAQs
What is the assumption gap?
The assumption gap is the difference between what a project team assumes to be true and what has been verified. The wider it is, the more likely the project is to hit surprises in scope, cost or adoption.
Why do projects fail because of assumptions?
Because assumptions quietly shape requirements, designs and estimates. When one turns out to be wrong, everything built on it has to change, and the cost of that change grows the later it’s discovered.
What is an assumption log?
An assumption log is a simple register of everything the team is taking for granted, with an owner, a way to validate it and a status. It works alongside the risk register and issues log, and it makes the assumption gap visible.
Can a business analyst close the assumption gap?
Yes. Business analysts specialise in questioning, validating and documenting what stakeholders believe. Techniques such as assumption mapping, 5 Whys and prototyping give them practical ways to turn guesses into evidence.
Final Thoughts: Make Assumptions Visible Before They Become Expensive
Projects rarely fail because people were careless. They fail because reasonable-sounding beliefs went unexamined for too long. Closing the assumption gap doesn’t require a new methodology, only the habit of asking “how do we know?” early, and writing down the answer.
Ready to build that habit professionally? Enquire about a business analysis course today, learn more about us, or call 1300 649 299 to speak with our team.