The post-mortem said the integration failed. Technically true, and completely beside the point.
What actually happened was that two teams left a meeting eight weeks earlier each believing they’d agreed on something. They hadn’t. Neither one checked, because both thought it was obvious. The code did exactly what each team thought was right. It was the understanding underneath that was wrong.
That’s the shape of most project failure, once you strip away the technical language people use to describe it.
I’ve spent a lot of my career untangling projects in trouble, and the pattern is remarkably consistent. The capability is usually there. The people are usually good. What’s broken is almost always something in the space between them: a conversation that should have happened and never did, a decision everyone interpreted slightly differently, an assumption nobody said out loud because it seemed too obvious to mention, right up until it turned out three people were each holding a different version of it.
The technical work is usually the part that goes right. It’s the words around the work that let you down.
This is uncomfortable, because communication failures are harder to point at than technical ones. Nobody writes “we misunderstood each other” in a lessons-learned document. It sounds soft. It sounds like nobody’s fault, which somehow makes it worse than a fault you can name.
So we reach for the technical explanation instead. The integration failed. The requirements were unclear. The vendor underdelivered. All of which might be true, and none of which is the actual cause.
The gap between “I assumed” and “I confirmed” has killed more projects than any engineering problem I’ve seen.
What makes this hard to fix is that it doesn’t feel like a problem while it’s happening. Everyone’s being professional. Meetings are held, notes are taken, updates are shared. The machinery of communication is running perfectly. It’s just not producing shared understanding, and the difference between those two things is invisible until something breaks.
It’s the same failure mode that lets a project sail through a locked schedule and a locked budget while the outcome quietly degrades. Everything looks right on the surface. The problem is happening underneath, where nobody’s looking.
When a project starts sliding, the instinct is to dive into the technical fix. Resist that for a moment and ask a simpler question first: does everyone actually understand the same thing?
Get the right people in a room. Have them say plainly what they assumed, what they expected, what they believe was agreed. It’s a slightly awkward conversation and it takes an hour. The real problem is often sitting right there, in the gap between versions, and once you close it the technical fix usually becomes straightforward.
Better still, build the habit before things break. Make it normal for people to say what they think was decided, out loud, and check it against what everyone else heard. It feels redundant. It isn’t. The half hour you spend confirming an assumption is cheap insurance against the eight weeks you’ll spend unpicking it later. This is a large part of what actually delivering a project looks like in practice, well away from the frameworks.
The best communicators I’ve worked with weren’t the most articulate. They were the ones willing to ask the obvious question and risk looking slow. That habit saves projects.
Ben Webb is an award-winning project leader and strategist. Named Australian Institute of Project Management Project Manager of the Year in 2022 and nominated for the International Project Management Association’s World Project Manager of the Year in 2023, he writes about delivery, leadership and the difference between managing a project and actually getting it done.
Leave a Reply