Why IT projects keep failing for the same reasons, and why everyone in the room already knows it, yet no one says a word.
There is a particular kind of silence that settles over project meetings when everyone in the room knows something is catastrophically wrong, but and no one says it.
The budget is unrealistic.
The deadline is impossible.
The vendor is failing.
The sponsor is disengaged.
The risks have been logged, reviewed, and politely set aside.
The biggest elephant in the room of IT project management: not ignorance of risk, but the collective, tacit agreement to ignore it.
Projects do not fail because project managers lack technical knowledge. They fail because social, cultural, and psychological forces create invisible walls around inconvenient truths. These failures repeat, not occasionally, but with the inevitability of a herd of charging elephants rampaging down a steep hill – something is going to get trampled. And so it is, project after project, organisation after organisation.
“The single biggest problem in communication is the illusion that it has taken place.” — George Bernard Shaw (*)
WHIPSNADE – A LESSON FROM REAL ELEPHANTS
Many years ago, my PM friend Paul was at Whipsnade Zoo when he happened upon some actual elephants.
They weren’t in an enclosure; they were being guided through the park on what they called an “elephant walk”. They weren’t tethered or leashed; they were walking side by side with their keepers, each elephant holding onto the tail of the one in front with their trunk.
Paul asked a keeper how his colleagues were herding the elephants like that.
The keeper’s response is mentioned by Paul whenever we discuss “the elephant in the room” in IT Projects:
“You don’t herd elephants, you lead them,” said the keeper. What a brilliant mantra for IT project teams!
First, let’s address some of the elephants that are hiding in plain sight in our IT project portfolios and then work out how we can lead them.
“The most dangerous knowledge in a project is the kind that everyone holds privately but no one voices collectively.” – David Cotgreave, 2026
THE SIX ELEPHANTS NOBODY WANTS TO NAME
These are not wild, rare and exotic edge cases. They are structural features of how organisations deliver technology and they appear, with remarkable consistency, across industries and geographies.
- Ignored Risks
Teams see the warning signs. They log them in risk registers. Then, driven by fear of the messenger being shot, they stay silent in steering committees.
- The Lessons Learned Paradox
Post-mortems are written. Recommendations are filed. The next project kicks off and makes the identical mistakes. Institutional memory is ceremonial, not operational.
- Software Failure Blindness
Leaders who would never promise a bridge will be completed with 60% of the steel still routinely sign off on software projects with fundamental unknowns unresolved.
- Human Factor & Miscommunication
Technology projects are fundamentally human endeavours. Poor communication and eroded trust between teams quietly collapse delivery capability long before a deadline appears.
- Agile Misapplication
Agile ceremonies can become theatre, with sprints and stand-ups that signal activity while masking an absence of coherent value delivery or genuine iterative thinking.
- Opacity
In large public-sector programmes, lack of transparency goes unaddressed because the incentives to name it are outweighed by the risks of doing so.
WHY DO ELEPHANTS PERSIST?
“The tar pit of software engineering will continue to be sticky for a long time to come.” — Fred Brooks, The Mythical Man-Month (1975)
None of this is new.
These elephants have been trampling on our project outcomes for years. So, why do they show up time and again?
There are several reasons:
- Fear: Breaking bad news to senior stakeholders carries career risk. Silence is rational self-preservation.
- Cognitive bias: Optimism bias and sunk cost fallacy distort how teams read their own evidence.
- Cultural resistance: Organisations that reward confidence suppress the very signals that would save them.
- Broken processes: RAG statuses, risk logs, and governance frameworks become rituals detached from reality.
TAMING THE ELEPHANT: FOUR COMMITMENTS
Each elephant cannot be wished away.
But, like Whipsnade’s Ming Jung, Donna (also known as Geetha), Lucha, Kaylee, and Nang Phaya – they can be named! Naming your elephant, and, more importantly, creating the conditions where naming it is safe, is the foundational act of genuine project governance.
So, let’s make four commitments to each other and our projects:
- Create psychological safety: Risk-bearing information must flow upward without penalty. Leaders who shoot the messenger will eventually run out of messengers, and the elephant will grow unchallenged.
- Shift from risk identification to risk action: A risk that is identified and then managed identically to one that is not identified is just bureaucracy. Risk management must be proactive and consequential.
- Institutionalise radical transparency: Project health reporting should reflect reality, not aspirations. Stakeholders who receive accurate information, even uncomfortable information, can make better decisions.
- Acknowledge and act, in that order: Acknowledging an elephant that you then ignore is worse than not acknowledging it at all. Naming the problem commits the team to resolving it.
HOW PMaaS ADDRESSES WHAT INTERNAL TEAMS CANNOT
The structural reason elephants persist is that the people best positioned to name them, experienced project professionals, are often the ones most embedded in the political dynamics that keep them invisible.
PMaaS introduces something rare: credible, experienced, genuinely independent oversight. Like those Whipsnade elephants, ours need leadership too. Here’s how PMaaS can help:
- Independent voice: External PMs have no internal political stake. They can name what internal teams cannot, without career consequences.
- Cross-portfolio pattern recognition: PMaaS providers see the same failure modes across dozens of clients. They recognise the elephant’s footprint before it becomes visible to those inside the project.
- Operationalised lessons learned: Rather than post-mortem documents, PMaaS embeds institutional knowledge from prior failures into live project governance, making lessons actually learned.
- Structured risk cadence: Regular, structured risk reviews led by experienced practitioners ensure risks are actively managed, not merely recorded and archived.
- Communication architecture: PMaaS designs the communication frameworks that prevent human-factor failures, with clear escalation paths, stakeholder mapping, and conflict resolution protocols.
- Transparency by design: Governance dashboards, honest RAG reporting, and executive briefings that reflect project reality, not what stakeholders hoped to hear.
CONCLUSION
The elephant in the room of IT project management is, ultimately, not a technical problem.
It is a problem of courage, culture, and trust, the kind that no methodology or framework can solve by itself, but that can be enabled by the right structure, the right people, and the right incentives.
PMaaS is not a silver bullet, but bringing in experienced, independent project professionals who have seen the same elephant in a hundred different rooms, and who have nothing to lose by naming it, is one of the most effective structural interventions available to organisations that are tired of repeating the same failures.
The elephant is in the room. The question is no longer whether to acknowledge it. The question is who is brave enough to speak first, and whether the organisation has built the conditions that make speaking up safe.
More about Project Management as a Service from Stoneseed
(*) Quote attributed to GBS but often debated!
SOURCES: