Six ways to avoid IT project failure

An article published in Tivi at the end of the summer about Compile’s approach to sustainable software development attracted a lot of interest, which is why I thought I would share my thoughts on the factors enable successful IT projects in our experience. Once you’ve been on the job for long enough, you start to see repetitive similarities in both successful and unsuccessful projects. 

In my opinion, there are six things that are particularly strongly related to a successful IT project, each of which I will publish with my own short story. 

In order to succeed, it is a prerequisite that:

  1. we are open and don’t hide emerging problems
  2. we genuinely want to help the customer
  3. team members truly know what they are doing (and want to consider e.g. the sustainability of technologies and architecture in terms of further development)
  4. we spend time on continuously developing our skills
  5. we are realistic about the pace of our progress (neither over nor underselling)
  6. the members of the organisation support each other in difficult situations and no one is left alone with the problems.


Part 1: Being transparent and talking about problems

Let us start with our first point, namely the hiding of problems and the importance of transparency. I am particularly reminded of an unfortunate but educational experience from a few years ago, when I formerly worked as a client ordering consultation services. 

We hired a team that seemed to be capable for the project. The team’s task was to implement a financial reporting system that processes data forward and is based on multiple data sources. After a few months, we began doubting the progress of the project, but the team assured us that everything was in order and that the project was proceeding according to the original schedule. We took the team at their word and let the work continue. However, after following the situation for four months, I had to intervene, as the code was completely inoperable and terribly poor in quality: the system did not retrieve the correct data, the structure was illogical and correcting errors only caused more errors. If the team or the supplier had admitted in good time that they had problems with the development work, we could have helped them. However, we had to change suppliers, and the new team naturally had to start from scratch. So, we lost a total of ten months of valuable time just because this supplier did not dare, want or understand to admit the problem. 

Does that sound familiar? Unfortunately, there are countless stories like this, where the supplier does not dare to report the problems to the customer. The extent of the problem is well explained in the comment made by one of our current customers, when we recently told them that the project would be delayed my a month. The customer thanked us for the transparency and said that this was the first time ever that a supplier has had told them on their own initiative that the project is behind schedule.

Striving for transparency, trust and sustainability of operations are values that many people promise, but do not deliver in practice. We believe that we can resolve things ourselves, and we may be too proud to ask for help. However, such situations can greatly increase unnecessary stress on all sides, and knowing that it is impossible to achieve the set goals does not increase the motivation of developers in the slightest. Of course, a project that has been going on for months also means that enormous amount of financial resources is wasted. 

A corporate culture based on trust and transparency is particularly important here. Let us support each other and try to solve problems together when we don’t have the strength to do it on our own. The earlier you bring out impending challenges (both within the team and with the customer), the sooner they can be addressed and you can prevent the problem from escalating. This will help to improve code quality, reduce regression and accelerate production, i.e. promote human and economic sustainability, among other things.

Next, more on the second point, i.e. the genuine desire to help the customer. What do you think is a prerequisite for a successful IT project?

the eNPS calculation is based on the Employee Net Promoter Score formula developed by Fred Reichheld, which was originally used to study the customer experience and customer satisfaction of companies. Lately, it has also been used to research employee satisfaction (e as in employee + NPS).

This is how the calculation is performed.

We ask our employees once a year, “How likely are you to recommend your workplace to friends or acquaintances on a scale of 0 to 10?” Then we ask for clarification with an open question: “Why did you submit this score?”.

Those who submit a score of 9 or 10 are called promoters. Those who submit a score from 0 to 6 are called detractors.

The eNPS result is calculated by subtracting the relative percentage of detractors from the relative percentage of promoters. Other answers are allocated a score of 0.

The calculation results can be anything from -100 to +100. Results between +10 and +30 are considered to be good, and results above +50 are considered to be excellent.