IT-companies go through similar problems and make about the same mistakes. Yet they have different conclusions. Sergey Vardomatski manages the HQSoftware team and knows all the obstacles it went through. Now Sergey talks about what the company has learned from the previous mistakes.

The company has determined a set of principles that we try to follow. They are the results of our mistakes.

Project management success team

1. Building well-established processes in the company and projects in particular

The processes let employees know and understand their role and responsibilities. But neither bureaucracy nor rules can replace employees’ own brains. Therefore, it is necessary not only to promote freedom of action and decision-making but also sometimes give people a little nudge. Self-sufficiency is a competence that can be and should be developed.

2. Taking care of the team. It is important to save people from burnout under stressful conditions

The world is not perfect and the customer’s requirements are never complete and also always change naturally as the product develops. Managers and analysts have their own issues, such as aligning the client’s business goals with available resources. Stress is increasing, therefore we build recreation areas, hold teambuildings, forbid working on weekends without approval – these things are mandatory. As well as the rule to regularly rotate people between projects, put emphasis on clarity in project management and analysts’ work.

3. Not doing projects that are doomed to failure

We have a strong team of sales managers who bring outstanding opportunities so that we do not have to start every proposed project to only make money and under fear of unemployment. We are not down to the amount of work and can develop self-management skills and expand gradually. If we take such a project, the failure will demotivate the team, we risk losing people who are the main resource of any business.

4. We must strive to be at the cutting edge of technology

This is good for both sales purposes and team development. Of course, we still have to work with legacy systems, but the balance is important.

Working with people we have faced different problems, we either did solve them or at least tried to, learned important lessons and moved on. Sometimes, mistakes are more important than success.

For example, nobody likes to work with old technologies, but the industry can not get rid of them. The developers want to work with the newest and trendiest, but this can not happen all the time. Usually, 80% of the work is routine, and 20% is new and cool tech, yet immature one. So when a big customer turns to us, he will not be ready for the newest and fashionable tech and platforms. They are mostly unreliable, and it is important for the customer to be able to support his solution if there is no developer.

We are trying to not get bored by the old technologies, and there is an excellent example. One of our projects is an online academy of one of the largest car manufacturers. It was a cool multinational project, but from the developers’ point of view, it was just 20 websites on Joomla. The client was very reliable and predictable, it was pleasant to collaborate for a long time. It seemed that we have been doing something extremely important and valuable for the world, we taught people to drive safe and now we can even measure how many lives we have saved thanks to this project, and this is awesome. But remember that this project is still 20 sites on Joomla.

Obviously, it was hard for developers to run this project – it was difficult to cope with and had lots of dependencies. A total headache. The project is more than 8 years old, we were trying to get rid of the technical debt and rudimental features, but sometimes the customer requirements were less coordinated than the developers wanted. We even did not have the opportunity to switch from Joomla to another CMS – it was a corporate standard of the client. We were aware that the developers would not like it.

Software development team

So we decided to transform this project into a “school” for developers, and the customer agreed:

  1. This project is a launching pad for the specialists who only know Joomla, for example, people from web design studios who want to become web developers. Here we teach them development processes and give time to improve their technical knowledge.
  2. The person works on this project no more that one and a half years and that’s all.

One and a half year is a perfect period for a person to delve into the culture of the IT-company, familiarize with more recent technologies, which sometimes are used in this project. Even Virtual Reality is applied sometimes.

The same is true for complex enterprise projects with large teams, it is easier to rotate people here. We always plan in advance that people do not stay on such projects for too long, because they burn out, get tired, and dismiss. Our business model requires that employees work for us more than for two years, so we are doing our best to save people.

The team is the greatest value for us. Therefore, we take care of it and organize the workflow thus the person does not get bored, we let him switch to something new and fresh. Doing this we can spot people who want to learn and develop. Employees who are comfortable with before-mentioned projects with lots of routine tasks can work there longer that one and a half year if they want to, but this is a rare case.

About the most disastrous project: we worked with a part of the Public Services Portal of the Russian Federation 8 years ago. There were some working process issues:

  1. We got ourselves in a situation where there were intermediaries between us and even an intermediate customer who isolated us from the client. We could not affect the process of communication in any way, as we were separated from the decision-maker.
  2. The whole process was extremely chaotic. Our customer communicated with his client, gathered requirements to hand them to us, saying “it should have been done yesterday” or “the mayor of Moscow will arrive tomorrow to see the demo”. We heard it like every day. It also was no longer possible to stop the project – in this case, the customer would not pay the bill for two months. The mediator, who was responsible for these risks, could not fulfill his obligations. As a result, the whole mess had quickly created loads of stress and the employees began to quit.

The project failed and we didn’t get paid. This project was very large at that time and we were nearly bankrupt. HQ didn’t shut down only because we still got enough character to continue.

Team of software developers working in a vibrant office

What have we learned here?

First, do not work with the customer indirectly. Take responsibility for the project and manage it with no intermediary persons.

Second, do not give in to manipulation and blackmail, it is a strong sign of failure. So, treat this customer like he is already gone and you have nothing to lose.

Third, build proper business processes inside your business – this is the best care for your team. When the manager is good, people will be pleased to work with him even if the tech stack is boring. The team feels protected, the members have clear expectations and realistic deadlines.

We will adhere to the same principles, remember the lessons learned and apply knowledge in practice. Always set up clear processes, take care of the team, abandon obviously failed projects, and work with old technologies and languages within reasonable limits.