IT projects in Germany fail more often than most people would like to admit. And more often because of processes and planning than because of technical problems. Too much upfront effort, too late involvement of partners and missing clarity about the actual why are the most common causes. Studies show that more than half of all large IT projects exceed their budget or fail to deliver the planned results.
I have seen many IT projects from the inside over the last 20+ years. As a consultant, as someone who implements things, and sometimes as the person called in when it is no longer working.
And I can say: most projects do not fail because the technology was wrong. Not because the team was incompetent. And not because the budget was too tight.
They fail because too much energy flows in the wrong direction right from the start. Long before the first line of code was written or any changes were made to a product.
I have genuinely seen this over and over again and I think: most of it comes down to mindset. Trust in external service providers is extremely low, everyone wants to protect themselves because they have had bad experiences in the past. And that leads directly into the next mistake.
Where does this come from?
My theory: it comes from the large failed projects of the past. They must have left extreme marks.
A scenario everyone has heard before: 600,000 euros budgeted for an ERP rollout. In the end, 1.1 million was spent. The system still runs shakily today, the staff hate it, and management eventually declares the project complete because there is no other choice.
What happens next? Panic. Someone has to answer for it. The budget is burned, the result is embarrassing, and somewhere in the company's collective memory a sentence takes hold: this must never happen again.
Understandable so far. Who would want that?
But the mistake happens again in the next step. The assumption about why it failed: we did not plan thoroughly enough. Next time plan more carefully, set up thicker contracts, add more control instances for more safety.
So the next project looks like this: twice the project team, an additional audit committee, one more external consultant, a 400-page requirements document, and weekly status meetings where people talk about risks instead of solving problems. And without exaggeration: we have accompanied projects where there were more project managers than people actually doing the implementation.
And what happens? The same thing. Only this time with 18 months instead of 12, more budget burned, and in the worst case a result that missed the market because the world moved on again in the meantime.
From my perspective this is not an isolated case but a pattern that comes up extremely often.
The fear of failure is what drives costs up in the first place. Those who try to prevent failure at any cost pay for it with speed, money and the ability to adapt.
Trying to secure everything is the biggest risk
I understand the impulse. Those responsible for a large IT project want to protect themselves. So there are requirements documents, architecture reviews, discovery phases, risk analyses, budget approval processes and steering committees. All with the goal of creating safety.
What actually emerges is the opposite. Every additional layer of protection costs time and budget before a single problem has been solved. The effort for protection grows so large that the project becomes immovable, slow and error-prone. The protection itself becomes the biggest risk.
And the bad thing about it: the requirements worked out in finest detail are often already outdated by the time implementation begins. Six months of planning for a world that no longer exists.
The concept of rigid upfront planning comes from a time when software projects were genuinely so complex that intensive preparation made sense. Monolithic systems, no cloud, barely any way to test things quickly. Today those premises hardly hold. And yet many enterprise projects still operate exactly the same way.
Energy flows in the wrong direction
Here is something I will never quite understand.
Companies first build a gigantic infrastructure for planning instead of solving the actual problem. Months-long discovery phases, architecture boards, budget approvals across three escalation levels. In total these processes consume more resources than the actual project itself.
The energy that goes into alignment, documentation and protection is missing at the only place that actually matters: the real problem.
What I think makes more sense: most energy should flow into two things right from the start.
- First, describing the problem. Not the solution, the problem. What is concretely broken, too slow, too expensive, too unreliable?
- And second, the why. Why is this project happening at all? What changes when it works? And what happens if it does not get done? Those who cannot clearly answer the why have not yet understood what they are actually trying to solve.
Learn to fail. Seriously.
Failure is not something negative. It is the fastest way to check whether you are on the right track, and you always learn something from it.
If an idea, a feature or a technical approach does not work, I want to know that as quickly as possible. Not after twelve months and half a million euros. Much rather after a 20K investment already in week three.
That is why I strongly believe in building something tangible early and testing it step by step. The advantage: you see results early and can talk about them internally. Feedback on something people can already touch and try is more honest than feedback on a requirements document that nobody actually reads anyway if we are being honest. And it ensures the future users engage with it early rather than at the end of the project when nothing can be changed anymore.
This is an underestimated point. Many projects fail not because the solution was technically wrong but because nobody wanted to use the system. Because it simply does not do what people actually need. You only find that out if you show what you are building early and get honest feedback. Those who do this at the end of the project always do it too late and end up constantly trying to get the team back on board, as they say.
The biggest risk of an IT project is not that it fails. The biggest risk is finding out after twelve months when the budget is gone.
A validated approach with 90 percent of budget remaining is more valuable than a failed year-long project that nobody wants to touch. And because so much effort has already been invested by that point, companies keep investing anyway. They feel there is no other choice but to push the project through to completion somehow.
Bring the right partner in early
A company spends months on groundwork, develops requirements internally, writes a specification, issues a tender, and only then looks for a partner to handle the implementation.
That partner arrives into a project that is already pre-thought and pre-defined. They can barely ask fundamental questions without being seen as disruptive. They are supposed to deliver what is described, not question whether the description is correct. And it is clear why: by this point everyone has already invested enough time and energy in the groundwork. Everyone is relieved that phase is over. But what if there was already a fundamental mistake in the initial thinking?
A partner who is there from the beginning can help describe the problem correctly. They can say early on when assumptions are off. That is their real value, not executing a finished specification.
But since a tool selection and a partner for implementation are often chosen at the same time, this is a chicken-and-egg problem.
Communication is not a side issue
IT projects also often fail because of communication. And that sounds like a soft problem but it is one of the hardest.
When requirements get lost between the business and IT. When nobody tells the client that an approach is not working because it would be uncomfortable. When status reports show green until the crash. These are communication problems with structural causes: wrong incentives, hierarchies that punish honest feedback, nobody with the courage to speak uncomfortable truths.
I have learned to say directly when something is a bad idea. Even when someone is paying for it. That is sometimes uncomfortable. But it is the only way a project can actually work.
IT projects that fail are not disasters. They are completely predictable and the result of too much complexity.
If you have an IT project in planning and want to know whether the underlying assumptions are right, talk early to someone who answers honestly. Not once the specification is finished.
— Robert
