SIX WAYS TO AVOID AN IT PROJECT FAILURE, PART 3: SKILLED TEAM MEMBERS

We recently announced that our personnel increased by a vigorous 61% this year, which gained us much deserved visibility related to the topic (Taloussanomat,,Helsingin Uutiset, Insinööri magazine). In particular, the media highlighted the generous salaries we offered to our experienced software developers, and I thought that I would explain our reasoning behind it a little more thoroughly.

In our opinion, one of the basic pillars of a good employment relationship is that when you require a lot from the developers in terms of competence and attitude, you must also be prepared to pay generous compensation for it. Salary is an important part of job satisfaction, but on its own it does not guarantee it. When the goal is a satisfied employee who enables high customer satisfaction, time and money must also be spent on continuously developing competence and creating and maintaining an organisational culture that supports the employee. Skilled colleagues also play an important role in this.

The most important single component for sustainable software development and successful IT projects is therefore human sustainability. Satisfied, committed and skilled employees enable the implementation of technically sustainable solutions that are cost-effective in the long term. Therefore, the skills should be at a level where the developers do not only concentrate on the the job at hand, but are able and interested in thinking about the further development of technologies and architecture in the coming years. These set of skills usually develop with time, having learned (possibly the hard way) to leave the code in better shape than it was when you started.

Every project should cover at least the next 5–10 years, as further development is an important part of customers’ business. Software maintenance becomes much more difficult and further development requires a lot of time and money if the future is not considered from the very beginning.

Let’s take a look at a related practical example that is based on real events.

One of Compile’s developers worked on a project, for which a separate external unit provided services. Previous services related to the operating environment had all been made with a certain technology stack, but now the necessary new service had been created with completely different technologies, including a data access layer. Our developer’s mission was to automate the infrastructure of services, and he thought out loud why a whole new solution that did not fit the current model in any way or form was suddenly introduced.

When the rest of the system started to be ready, serious performance issues began to emerge in the new data access layer. When our consultant investigated the issue, he found out that the team that created the new service did not have a profound knowledge about their chosen technologies. Therefore, it was left to our consultant’s team to solve the problems.

Our consultant began to raise issues more diligently, which revealed that the customer had no idea of the amount of technical debt of the project in question and no plan for what to do in the future. Thanks to raising those issues, it was possible to bring some of the service into the existing architecture. However, the biggest bottleneck, the selected database, remained a nuisance to everyone in the service costing a considerable amount of money.

In this case, the problem was that the consultants in the other unit wanted to experiment with new solutions, regardless of maintenance and further development. Of course, you do not have to do everything in the same language or with a specific database, but you cannot suddenly re-install the whole package without taking responsibility for the consequences. The customer trusts that the consultants will bring them the solutions that will benefit them not only today, but also tomorrow. Solid expertise is strongly associated with the understanding that someone else should be able to continue the work. In many cases, this understanding only comes with experience, when you have tried to maintain a low-quality code yourself.

In order to succeed in customer projects, we therefore emphasise sound expertise. When developers’ know-how is at a sufficiently high level, they are able to arrive at technically sustainable solutions, which in turn save a considerable amount of resources in the long run. Sensible technical and economic solutions, in turn, enable a smaller ecological footprint.

The following text further addresses competence from the development point of view. You can also return to my previous articles on the prerequisites for the success of IT projects: the importance of transparency and a genuine desire to help the customer.

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.