Six ways to avoid IT project failure, part 6: Supporting members in your organisation

I have published a series of articles on the prerequisites for the success of an IT project on our blog, and there is only one more topic that is very important in our experience. Previous articles addressed the importance of transparency, a genuine desire to help the customer, hard-core competence, time spent developing skills and realism in terms of pace of progress. As a logical continuation to this list highlighting people-oriented software consulting, we will address the support that members of an organisation give each other.

As I have said before, human sustainability lays the foundations for sustainable software development. Our goal at Compile is to keep our customer satisfaction high, and that can only be achieved if our employees are satisfied. We strive to ensure the satisfaction and well-being of our employees in three ways: continuous development of competence, generous compensation for work and a corporate culture that supports the individual. I wrote about these first two already previously, but let us open up that third topic by means of a concrete example.

Two of our developers started a project for a new client, where the team was assembled from consultants from several different consulting companies. Everything seemed good at first, but after a few weeks, the feeling of concern began to grow. Despite the fact that everyone seemed to be working, the project was confusing and the team did not play well together. Several “micro-teams” had emerged inside the team, each doing things the way they considered best. The timetables stalled, but no one really highlighted any issues. 

Instead of patting our consultants on the back and accepting it, we asked them to come to our office for an internal meeting where the whole project was reviewed by our own team. We spent a few hours forming a realistic view of what can actually be achieved in the project. Once we had devised a plan that we could commit to, we started thinking about how to communicate the situation to the different stakeholders. We concluded that our consultants reviewed the findings with their team and our account manager raised the issue at the first steering group meeting. The customer took the matter seriously and immediately began to consider how to rectify the situation. In addition, they thanked us for raising the issue and took concrete steps at the necessary levels to reverse the course.

The easiest solution there would, of course, have been simply to spur our consultants on or pull them out of the project when things got hard, but it wouldn’t have helped anyone in the end. Neither a friend nor a customer should be left behind. Our task is to support each other in order to ensure our shared success and well-being. Consultants often feel alone at the customer’s premises and for us, the steering meetings every 1-3 months have served as an excellent way to assist with projects and ensure the satisfaction of both our consultants and the customer. The support that the consultants give each other is also extremely valuable and should be supported in the form of formal and less formal meetings, as well as through Slack.

It often seems that especially larger companies forget that software development is 100% human-oriented. If we could all keep this in mind, remember to talk about issues openly and in a timely fashion, and support and help each other, then we wouldn’t have to constantly read headlines about failed IT projects.

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.