Six ways to avoid an 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 that 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 a short narrative. 

In order to succeed, it is a prerequisite that:

  1. We are open and don’t hide problems
  2. We really want to help the customer
  3. Our team members are highly skilled (and willing to think about the sustainability of technologies and architecture with respect to further development)
  4. Time is spent on the continuous development of skills
  5. We are realistic about the pace of progress (no over-sales, no under-sales)
  6. Members of the organisation support each other in difficult situations and no one is left alone with their 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 allowed the work to continue. After monitoring the situation for four months, I had to intervene, however, because the code was completely inoperable and terribly poor in quality: the system did not retrieve the correct data, the structure was illogical and correcting the 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. We had to change suppliers, however, 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 by a month. The customer thanked us for the transparency and said that this was the first time ever that a supplier 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. Such situations can greatly increase unnecessary stress on all sides, however, and knowing that it is impossible to achieve the set goals does not increase the motivation of developers in the slightest. Of course, if a project has been going on for months, it also means that an 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 up 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?

Tuntuuko, että...

 …teidän softakehitystiimissä sekä palautteen antaminen että vastaanottaminen on vaikeaa?

Tilaa ilmainen miniopas tilanteen ratkaisemiseksi tästä:

    Kun tilaat oppaan, liityt samalla uutiskirjeemme tilaajaksi, ja saat lisää inhimillisen johtamisen vinkkejä. Voit poistua listalta koska vain.

    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.