MMTR Technology is willing to share its experience in working with customers. One of our Project Management Officers, Oleg Lapakov has shared his opinion on why IT companies often fail to meet project deadlines when working with clients.

“Nobody intends to keep the client waiting. It must be an essential prerogative for every Project Manager to build up confident relationships with the Customer, in order not only to begin working on time but also to meet project deadlines. Often, however, insufficient attention to the project terms assessment can lead to long-term negative consequences.” Oleg Lapakov, Project Manager

At the end of March 2017, we began a project, provided by the Rosgosstrakh insurance company ( RGS or RGS Group ) – Kostroma. Initially, the terms were to develop the accounting and reporting systems for their agents within 360 hours. The date of the project development launch was decided on 20 / 03 / 2017. Respectively, the project deadlines were planned on 31 / 05 / 2017. The project development team consisted of five people: A Project Manager, two developers, one quality assurance engineer and one business IT analyst. At the moment of project development launch, neither the terms of reference documentation for the solution had been developed, nor had the list of requirements from the customer been presented.

“We did not even have a preliminary list of wishes and desires.” Oleg Lapakov, Project Manager

Unfortunately, the project is still not complete. Therefore, the question remains: “Why do IT companies fail so often to meet project deadlines”? So much has been written about Project Management; however, there has been no definitive answer given to this question.

Let’s highlight the key problems:


This problem arises when the Customer is not capable of providing the necessary and sufficient information regarding the company’s business processes. To make matters worse, the Customer is unable to connect these processes with their requirements for the developed solution. The Customer will not be able to formulate the exact requirements for the project until he or she understands the solution. To begin the project with uncertain client requirements and a lack of understanding of the end results means the project is doomed to failure. It is better to postpone the launch and work with the client to be better prepared for the project.


Without having accurately formulated requirements, it is impossible to begin project development. The team will continuously endure difficulties in managing the content of such a project, and as a result – it will lead to Customer dissatisfaction. Insufficientlyformulated requirements mean that the project content scope has not been definedor clarified. In this situation, it is important to postpone the development launch until all the details and Customer requirements are defined


Often Customers assume that it is possible to begin the project without a formally defined budget. Usually, in this case, the Customer is only able to afford part of the project. Later, there is a tendency to begin bargaining, to lower the price. There are often different ideas on pricing for each  project element that is developed. That is why, it is important to define precisely the project budget and financing terms, before launching project development and clarify all possible financial issues which may arise.


Sometimes – surprisingly frequently – right after project development has been launched, radical differences come to light between what was discussed at the requirements stage and what then develops.

After a month and a half of project development, when we showed the project preview to our Customer, it turned out that the data input business-process was directly opposite to the vision that had been initially confirmed, during our meetings with the Customer, to clarify the requirements.” Oleg Lapakov, Project Manager

In the very beginning of the project, it is vital to discuss with the client:

·       business processes,

·       project contents,

·       the potential solution

When you have managed to achieve  full understanding with a client, about what theend product will look like and what solution will be implemented, it is possible to move on to development.

In my opinion, after reaching mutual understanding, it is absolutely critical to record all of the arrangements in a full-fledged reference document including all of the terms, or at the very least the detailed concept of the product.” Oleg Lapakov, Project Manager


Sometimes it appears that the project manager launches project development without an officially approved team line-up. Such haste might overlook the fact that required employees are unavailable. This may lead to the involvement of third-party experts, which may not be included in the planned budget and be completely unacceptable. The addition of new employees, with the time needed for training, adapting and achieving efficient team interaction will most likely lead to an over-expense as well as non-compliance with project deadlines. That is why, at the beginning of the project, it is critical to have a completely created and wellmanaged team lineup with all the roles defined. Otherwise it is better to postpone the project development launch until the team is settled.

In our case, we have not faced this problem – the team was defined, created and well managed before the project launch.” Oleg Lapakov, Project Manager


Often IT companies face the situation where a Customer is inaccessible during project implementation, is unable to take part in key decision-making processes and not available for continuing project development. If this happens, then it is better to shift projects deadlines until the Customer is reached. To prevent this from happening, make sure you keep in touch with your Customer.

In one of our projects, we have repeatedly been facing a situation where we have to catch the attention of the customer’s key employees.” Oleg Lapakov, Project Manager


In practice, the kick-off meeting is often omitted and considered as a mere formality that is not crucial. We never recommend this. During the kickoff meeting, we make a final verification of the client’s expectations for the project. In other words, we verify the client’s requirements. This allows us to make sure that all sides have an identicalvision and have the correct information for the developed project. The length and formality of the meeting will depend on the size and importance of the project. If this meeting has not been planned or cannot be organised in the near future, then it is better to postpone the project development launch.

In this project, these meetings were not held and that, unfortunately, caused a lot of misunderstanding.” Oleg Lapakov, Project Manager


There is a situation that often occurs in which you have signed the service provision contract, between you and your Customer, without defining the formal leading roles. If everything appears stable on the Customer’s side, and there is only a Project Manager, they often think there is no need for a Project Curator (this practice proves that most of them are not aware of who the project curator is). Sometimes they merely assign a contact person who may be an ordinary analyst or system administrator. The projectCurator is extremely essential. He is responsible for the definition of project prioritieschange approval, project team communication, and of course, he is the representative of the Customers will. If the project lacks leaders from both parties, then the development launch should be postponed.

In our case, the lead of the project from the customer side was the system administrator – an employee with only an indirect idea of the business processes for the developed solution. It caused constant idle times for our developers during project implementation because we were forced to wait too long each time there were questions.” Oleg Lapakov, Project Manager

We would like to highlight several signs of problematic projects which are useful for identifying issues at the initial phase of the project. Separately, these signals can hardly foretell a project failure, however, having several of them should cause you to start questioning the worth of the project:

·  The project terms are too short and rigidly fixed.

In these type of situations, the potential client is often well aware of project deadlines. They spent longer in the project planning phase than expected, and now are passing on the shortened timeframe to the IT company that they are working with.” Oleg Lapakov, Project Manager

·  The potential client states, “We have no idea”, when asked about project financing.

This can only indicate that they have not managed to cope with their part of work and do not take the project seriously Oleg Lapakov, Project Manager

·  The potential client confirms that they have a budget but don’t give details.

Usually, this indicates that the client does not trust you and expects that you, the IT company, will overcharge at the end of development, which is obviously not true.” Oleg Lapakov, Project Manager

·  The client states the desire to develop the product as cheaply as possible, or their budget is very low.

This means that the client does not appreciate the value of the IT company, preferring the cheapest option to the best option. In these type of situations, potential clients who are spending their own money can be strongly limited.” Oleg Lapakov, Project Manager

·  The client expects much more from the project than the budget allows.

“In this type of situation, it will be hard to satisfy the client’s expectations” Oleg Lapakov, Project Manager

·  The potential client does not tell you how many other IT companies they have contacted regarding the project.

“This indicates that they have distributed their offer to other IT companies, seeking the best deal” Oleg Lapakov, Project Manager

·  The potential client has not spent the time to communicate all of their requirements for the project, and have neglected to answer the questions asked by the IT company regarding the project.

If the client is unable or not willing to spend the necessary time on the project, it means that the client does not take the project seriously.” Oleg Lapakov, Project Manager