IT projects can fail for many reasons. One of the most common causes is underestimating how long the project will take to complete and not staying on top of deadlines. This could happen because a deadline was set too soon or due to unexpected delays such as technical issues, changes in scope, team members leaving before work is completed, lack of resources, etc. Other factors that contribute are unrealistic expectations from stakeholders about what can be done within a given timeframe and developers getting stuck on one issue while other tasks pile up behind them.

To avoid these pitfalls it’s important to have realistic expectations about timeframes and create checkpoints throughout a project where you review progress towards completion with your team members so they know if they’re falling behind schedule or need help completing.

Also, there is something more. Something which not everyone thinks about. A few years back I was among these people as well, but it started to change after I was unsuccessful in an interview for a company located in Brisbane, Australia.

The question asked was pretty simple, and it was „you have a project. After estimations you see that it won’t fit in a given timeframe. What’d you do?„. At that time I was used to a simple answer „so if we want to deliver everything, we have to get more people” and the counterargument was „you can’t as this is a fixed-budged project„. „So we have to sit down with the client, go through all functionalities within the project, prioritise them, and we deliver as much as we can starting with the functionalities with the highest prio„. I remember that I was pretty sure this answer was correct and I was almost 100% sure I succeeded and have the job. The next day brought me a very unpleasant surprise. I was failed, although I received very detailed feedback on what went well and wrong and in which areas should I improve. The most important area was related to project handlings.

I was very surprised, not to say annoyed. I didn’t understand why my answer about how to handle the project was incorrect. Then I started following the resources I was given in the feedback and I started to realise that, yeah, even though my answer was correct, it was outstanding from the current, better ways of dealing with software deliveries.

So what did I miss? Most likely the same thing as you are missing right now.

Check the numbers and focus on the number of IT projects that fail each year. Depending on the source, you may see that up to 60% of projects succeeded in the last year. But that’s a very optimistic statistic. Other sources say that roughly about 30% of projects were an absolute failure, next 25-30% were a failure but something out of it could be used somewhere in the future, 20% was a moderate success as the main goals were delivered and only the rest, the remaining 20-25% were considered a full victory.

You may think why is that? Is majority people involved in SDLC so lazy or unprofessional or, frankly speaking, jerks?

I strongly believe that’s not true, but from time to time I have my doubts 🙂

The problem is in communication between tech guys and the client. In most cases, the client comes with an already written project which is split into features, milestones, and so on. It is well prepared, all edge cases are identified and described how a system should react to these issues. Someone spent a lot of time and effort for analysis, calls, and meetings with stakeholders, end-users, and so on. Based on that, IT guys assume that this approach is correct and the client precisely knows what it wants. Regrettably, this is only partially true as in most cases client only thinks it knows what is the best solution to achieve its goals or resolve its issues.

During my whole career and career tech gurus I follow, and statistical data, in most cases the client doesn’t know what he requires to achieve their goals or to resolve their issues. It knows its system and therefore tries to fit the solution somewhere within it. Sometimes this way may be correct, however, in most cases, it is not. On the other hand, IT guys take the proposed solution as something unquestionable and they build what the client wants. This is how the failure starts and it is not one fail. It is a series of failures on both sides.

How to avoid that kind of failure? Ask questions. Not about the proposed project and the solution it brings. Ask about the real problem and the real purpose or aim. What value it has to bring? Why it is so important? When it started and what prevented you from resolving it sooner? Those kinds of questions bring you closer to the real problem the client faces. After you are certain you precisely know what is the true client problem, assess the proposed solution it brought, and if you see it isn’t going to resolve the case, propose a new one. In many cases, your proposal will be cheaper and faster in implementation.