Why so many IT projects go off the rails — and how I prevent it
A pattern that comes up far too often
Too many IT projects arrive late, cost far more than planned, or deliver a tool nobody actually uses. This is not inevitable. After 11 years in the industry, 45 projects delivered, and more than 25 teams coached — at Allianz Trade, Chanel, MGEN, Air Liquide — I have learned to spot the warning signs before they turn into disasters.
The good news: these overruns have specific, identifiable causes that can be caught early. And they can be prevented.
The real causes of project overruns
A vague scope with no prioritisation
The first enemy of any project is imprecision. When nobody knows exactly what needs to be delivered — or when everything is treated as a priority — teams scatter their energy. Features nobody needs get built while the essential work sits waiting.
A poorly defined scope at the framing stage shows up in every sprint, every meeting, every trade-off discussion. The cost accumulates silently.
The tunnel effect: no intermediate deliveries
This is one of the most destructive patterns: a project that runs for 12 or 18 months without the client ever seeing anything concrete. Everyone waits for the "final version" before validating — and by the time it arrives, requirements have changed, the team has made assumptions, and adjustments are expensive.
The tunnel effect creates uncertainty for everyone: for the client who cannot tell where their money has gone, for the teams working in a vacuum, for management steering blind.
No governance and no visibility
A project without clear governance is a ship without a rudder. Who decides when there is a blocker? How do priorities evolve along the way? Who signs off on the quality of deliverables?
Without a defined framework, every decision becomes a negotiation and every unexpected issue becomes a crisis. I have seen projects stall for weeks on matters that could have been resolved in 30 minutes with the right process in place.
Technical debt and unnecessary custom development
Building an overly complex solution from the outset — because you are anticipating hypothetical future needs — is a classic mistake. Technical debt accumulates, maintenance grows more complex, and future changes slow down.
Custom development is expensive to build and even more expensive to maintain. A large share of the bespoke features built in the initial phase will never be used in their original form.
Broken communication between client and team
The last major driver of overruns is a breakdown in communication between the sponsor and the teams executing the work. Expectations are not stated clearly. Feedback arrives too late. Decisions are made without the right people in the room.
The result: you deliver what was asked for, not what was actually wanted. And the gap can be significant.
My concrete safeguards
Scoping and MVP: laying the foundations before building
Before a single line of code is written or a single team is mobilised, I invest time in scoping. What are the real objectives? Which features are essential from day one, and which can wait?
The MVP — minimum viable product — is not a cut-down version. It is the smallest possible version that delivers real value and allows key assumptions to be tested. It is what lets you start learning without having built everything first.
This upfront work prevents months of unnecessary development and painful mid-course corrections.
Sprints with regular demos: breaking out of the tunnel
I work in short cycles — two-week sprints — with a demonstration at the end of each one. The client sees what has been built, gives feedback, and validates or adjusts priorities.
This approach eliminates the tunnel effect by design. There is no "big final reveal": at each stage, everyone knows exactly where things stand, what is working, and what remains to be done. Corrections happen on an ongoing basis, not in a panic at the end.
A clear governance framework
Governance is the skeleton of the project: who decides what, how priorities are arbitrated, how quality is measured, how risks are escalated.
At Allianz Trade, I built this framework from scratch — processes, rituals, tracking indicators. In six months, the quality of delivery improved by 40%. Not because the teams worked harder, but because they were working within a framework that eliminated ambiguity and accelerated decision-making.
Governance is not bureaucracy. It is what allows a team to focus on execution rather than wasting time rebuilding the rules of the game at every meeting.
Full transparency: the client sees the progress
I work with complete transparency on the state of the project. The client has access to progress indicators, validated deliverables, and identified risks. No filter, no window dressing.
This transparency can feel uncomfortable at first — nobody enjoys seeing difficulties laid bare. But it is the foundation of trust. A client who sees problems as they emerge can help resolve them. A client who discovers them at the final delivery has no leverage left.
Controlled handover of operations
A project does not end at delivery. The operational teams then need to take ownership of it effectively. I plan this transition from the very start: documentation, training, knowledge transfer.
On engagements like Chanel — where I guided the onboarding of 120 consultants into agile ways of working — or at MGEN with the SAFe deployment, I learned that a successful handover is organised, not improvised. Operations must be managed with the same rigour as the build phase.
What this changes in practice
A project that starts with solid scoping, intermediate deliverables, clear governance, and fluid communication does not eliminate all surprises — no project can. But it turns surprises into manageable adjustments rather than crises.
It is the difference between a navigator with a map and real-time weather data, and one who simply hopes to reach port.
After steering 110 people on an agile roadmap and synchronising 6 teams at Air Liquide, I am convinced: a project does not go off the rails by bad luck. It goes off the rails by lack of structure. And that can be prevented.
Let's talk about your project
Do you have an IT project underway or in preparation, and do you have questions about methodology, risks, or organisation? I am happy to have a direct conversation about your specific situation.
WhatsApp: +33 6 34 42 50 56 Email: contact@twentyconsultancy.com
No commitment, no jargon. Just an honest outside perspective on what you are building.