Every failed project has a story. Sometimes it’s poor planning. Sometimes it’s unrealistic deadlines. Sometimes it’s weak leadership. But if you dig deep enough, you’ll almost always find one common thread. Someone assumed something. “We assumed the requirements were final.” “We assumed IT was handling that.” “We assumed the customer approved the design.” “We assumed procurement already ordered the equipment.” “We assumed everyone understood the plan.”
Assumptions are quiet. They don’t announce themselves. They sit in the background until the exact moment they become expensive. By then, the damage has already been done.
We fall for this because assumptions feel like facts. That’s what makes them dangerous. Most assumptions don’t sound uncertain. They sound obvious. “Of course, Legal will review it.” “Engineering knows what we need.” “The sponsor is on board.” “Finance already approved the funding.” Everyone nods. Nobody verifies. Project teams begin building plans on beliefs rather than facts.
The problem isn’t that assumptions exist. The problem is treating them like confirmed information.
But every single assumption is a hidden risk. I teach that risks are future uncertainties that could affect project objectives. An assumption is simply a risk wearing camouflage. If you’re assuming something is true without verifying it, you’ve accepted uncertainty. That uncertainty belongs in your risk discussion.
Ask yourself: What if this assumption is wrong? How would it affect our schedule? What would it cost? Who owns verifying it? When will we know for certain? Those simple questions turn dangerous assumptions into manageable risks. Ignoring them turns manageable risks into expensive issues.
“I thought they were doing it.” Is a hidden project killer. In fact, few sentences have cost organizations more money. Projects rarely fail because people are lazy. They fail because responsibilities were never crystal clear. One team assumes another team owns testing. The vendor assumes the customer is providing training. Operations assumes implementation includes documentation. Leadership assumes someone else is tracking dependencies. Everyone believes someone else has it covered.
Nobody actually owns it.
Ownership isn’t established through hope. It’s established through explicit assignment. If every deliverable doesn’t have one accountable owner, don’t be surprised when nothing gets done.
One sentence in a requirement can create months of rework. “The system should be user-friendly.” What does that mean? “It needs to be fast.” How fast? “It should integrate with existing systems.” Which systems? “It should support reporting.” What reports?
Vague language forces people to make assumptions. Every assumption creates multiple interpretations. Every interpretation creates the possibility of rework. Clarity isn’t about writing more. It’s about eliminating ambiguity.
One of the biggest mistakes project managers make is ending a meeting with: “Any questions?” Silence.“Great, everyone understands.” No. Silence might mean agreement. It might also mean confusion. Or distraction. Or hesitation. Or fear of looking uninformed.
Instead, ask people to explain their responsibilities. “What are your next steps?” What deliverable are you responsible for?” “What dependencies concern you?”
Now you’re validating understanding instead of assuming it.
As deadlines approach, teams begin moving faster. Ironically, that’s when they verify less. “We don’t have time.” “We’ll figure it out later.” “It’ll probably be fine.” Pressure doesn’t eliminate assumptions. It magnifies them. The faster your project moves, the more disciplined your communication must become. Speed without verification isn’t efficiency. It’s gambling.
The best project managers I’ve worked with ask questions that others are afraid to ask. “What exactly do you mean?” “Who owns this?” “When will it be complete?” “How do we know?” “What happens if this doesn’t occur?” “Has anyone confirmed that?” These aren’t annoying questions. They’re leadership questions. Good project managers remove uncertainty. Great project managers prevent expensive surprises.
That’s why I advise my clients to build an assumption review into every project. One habit can dramatically improve project performance. Ask your team regularly: “What are we assuming right now?” Write every answer down.
Then categorize each one: Verified. Needs confirmation. High risk. Invalid. It’s a simple exercise. But it exposes hidden threats before they become schedule delays, budget overruns, or executive escalations. You’ll be amazed at how many “facts” are actually guesses.
Whenever someone says: “I think…” “We believe…” “They usually…” “They always…” “We’ve never had a problem before…” Pause. Ask for evidence. Not opinions. Not optimism. Evidence.
Good project management isn’t built on confidence. It’s built on verified information. Confidence without evidence is just another assumption.
Projects rarely collapse because of one catastrophic event. More often, they fail because of dozens of small assumptions that nobody challenges. One misunderstood requirement. One undocumented decision. One unassigned task. One dependency nobody verified. One stakeholder who thought someone else was handling it. Individually, they seem insignificant. Together, they derail projects.
As project managers, our job isn’t simply to keep work moving. It’s to expose uncertainty before uncertainty exposes us. So the next time you hear someone say, “I assumed…” Stop. Ask the question that separates average project managers from exceptional ones: “How do we know that’s true?”
That single question can save weeks of rework, thousands of dollars, and the credibility of your entire project. Because in project management, assumptions are free.= The consequences never are.
