IT-Projects Disasters: Avoidable Reasons IT Projects Fail

Let's be honest, friends. How tedious is it to stick to a release date every time? And what tricks have we not all pulled out of the pocket in order not to blow the budget? I'm sure you all know the feeling when the deadline is missed and the budget pot is suddenly empty, but the backlog is not. First of all, this is somehow normal. On the other hand, we should think about whether this is acceptable and what we could do about it, and that is exactly what we will do in this article.

The CHAOS report

Do you have a gut feeling for how many IT projects worldwide can be classified as successful? Think of an approximate percentage and make a note of it for later.

I don't know if you have ever heard of the so-called CHAOS Report by the Standish Group. The CHAOS Report is a large study that examines the quality of software projects worldwide. It has been around since the 90s and conducts thousands of it-projects every year, so I think it is fair to say that we have some representable numbers here. What the study does, it classifies projects into 3 categories:

1. First one is called "successful", which means that projects are completed on time and budget
2. Second one is called "challenged". Challenged projects are completed EITHER on time OR on budget
3. Third one is called "failed". Projects are aborted or completed neither on time nor on budget

Looking at recent data, we see that about 30% of all projects are classified as successful, while 20% of all projects fail. About 50% of all projects are considered "challenged". Does that match the number you had in mind from earlier on? What do these numbers tell you? To me it basically says: About 70% of all projects are not considered as "successful". To be honest, this is a disgrace for our industry! Can you name another industry where the chances of success are so low that clients are told: "We'll do the project, but there's a 70% chance it will be much more expensive than expected or that you won't get what you wanted." Imagine such a statement in plastic surgery for example.

The shocking realization after the CHAOS report

The most interesting insight comes when you take a closer look at the figures for the last 20 years. If you insert trend curves into this diagram, you get almost horizontal straight lines. This means that the quality of software projects has hardly changed over the last 20 years.I repeat: almost no visible change in outcome quality in the last 20 years! That's crazy! I mean, how many conferences have we attended, how many talks on new technologies have we attended where the buzzword bingo counters went crazy with words like innovative, bleeding-edge, disruptive, revolutionary, next-generation, radical, pioneering, visionary, game-changing, bla bla bla...and so on!

Well...f*ck it! It obviously didn't change a thing! Technology seems to have no impact or at least it certainly is not the lever for change! They totally fooled us, made us believe that technological Jesus would come to save us all! I'm telling you something: it's not gonna happen.

A threat to digital transformation

In my opinion, the figures in the CHAOS report are quite sobering. Especially for an industry that prides itself on being home to the brightest minds and defining the future of the world. We are still in the midst of the age of digital transformation. Digital processes and solutions are gradually replacing the old, analog world. But the foundations we are currently laying for our digital future are pretty shaky. Imagine it like this:

Imagine a typical house in Venice, built in a canal and surrounded by water. These houses stand on wooden piles, which serve as the foundation for the house. Symbolic for the IT industry: statistically speaking, 70% of the foundations are already dilapidated (or "challenged") before the first stone of the future house has even been laid. Ask yourself: How much would you want to invest and live there?

Friends, this is serious business and we should take a good look at ourselves.

The reasons for the disaster

The people from CHAOS Report also asked the respondents to give their reasons. One might think that bad coding skills are the main cause for these results. This will certainly play a role, albeit a lesser one, because even if expensive engineers did not have a wide range of skills, programming would certainly be their strongest skill. In fact, quite different problems are cited as the cause:

• Lack of User Input: Projects often fail due to insufficient user input and feedback (in both directions) throughout the development process.
• Incomplete Requirements: Vague, incomplete, or constantly changing requirements due to imprecise communication.
• Unrealistic Expectations: Overly ambitious timelines and budgets often due to a lack of technical understanding on the client side and a lack of client-domain understanding on the engineering side.
• Poor Project Management: Ineffective management practices and lack of adherence to best practices contribute to project failures.

Interestingly, none of the reasons mentioned have anything to do with technology. Quite the opposite! This is essentially about communication and soft skills as well as understanding and executing processes. The problems are human, not technical. This also explains why the constant improvement of technology hardly seems to influence the success rate of projects.

It's actually crazy that we've known these numbers for almost 20 years and the reasons for it are also well known, but we're still not really doing anything about it. I regularly attend IT conferences, and on average, less than 10% of the talks and panels there deal with topics that are not directly related to technology and code. And that 10% is mostly about "agile" stuff.

Unused opportunities

I am certainly not calling for a global paradigm shift or a world revolution for soft skills. Ultimately, it is up to everyone to decide how they want to do their work. I can only address the entrepreneurial spirit of software companies and raise the question of why they voluntarily leave so much potential lying around? It is not only the CHAOS report that shows where major efficiency levers are hidden. There are numerous other studies that confirm this phenomenon. A study by McKinsey, for example, suggests that effective communication between team members can increase team performance by up to 40% by improving understanding and reducing conflict. To my ears, 40% sounds like an enormous added value that I would not let go unnoticed as an entrepreneur.

Final thoughts

Do you know what still amazes me today? It's actually completely atypical, especially for engineers, that although you know it, you don't tackle the biggest lever for increasing efficiency, namely the results of the CHAOS report: skills beyond code. Instead, I tend to experience the opposite behavior, a kind of rejection of topics such as soft skills and workshops. The word "meeting" is almost a dirty word in engineering circles :). Sentences like "Please don't invite me to the meeting, I have to work!" show the attitude relatively well. It's a shame really, because there is still so much untapped potential here.

If you were to ask me to name 3 measures to improve the quality of IT projects in the long term and turn the CHAOS report into a HAPPY report, I would say:

1. Train your engineering teams in soft skills and process execution. Precise communication, giving and receiving feedback, understanding group dynamics, people skills and much more are simply essential for efficient collaboration, no matter how good the technology of choice is.
2. Work continuously to close the understanding gap between the world of engineers and the world of customers, i.e. the technical world and the non-technical world. How can you develop a solution if you don't fully understand or care about the problem? And how can you be a stakeholder and participant in a digital solution process if you have no idea of the basic laws and necessities of the digital world? The two extremes must be brought closer together.
3. Work on your attitude towards software development. Software is not an end in itself. Customers don't buy technology, they buy solutions. Anyone who ignores this law and just wants to write nice code is living in their own matrix. This is a business world, and that is not a bad thing. The customer and their requirements are not the enemy that will ruin your perfect software…they just don't know any better. Instead, realize that with your expertise and problem-solving skills, you have the power to improve the customer's world and take it to the next level, which will ultimately benefit you. Even if it's just the day-to-day work that suddenly becomes really fun. You just need to be able to listen, understand and communicate properly.

What do you think? Contact us and let us know!

#CHAOSReport #DigitalTransformation #ProjectSuccess #SoftSkills #ProjectManagement #SoftwareEngineering

Utterskills - We are an e-learning academy for IT-professionals and provide micro learning video courses for all relevant topics beyond code in IT-careers. Did you like this article? Then you're gonna love our videos! Why don't you give it a try? It's free!