There are situations when the deadline is not just burning, but specifically, the chair on which the customer is sitting is already being burned. Taking on a project that is a month away from delivery, and the process has barely crossed the starting line, is not an easy task. Most experienced teams refuse such projects because these are big risks, but our team knows how, as they say, to play at limits and bring any business to the end.

What is all the salt?

The customer, – we will not divulge the name, let it be John, – met the team a couple of years before the “hot” situation at one of the conferences. After talking more closely, he handed over his project for an estimate, but in the end, he chose another contractor due to the lower cost. In fact, our team estimated the project twice as expensive, taking into account all the difficulties and risks.

The story could have ended there, but after a personal visit to the Ukrainian office and a closer acquaintance, John takes on a small team for another project. A month later, he asks to pick up another project, which we have estimated earlier. It turned out that there was only one month left before the completion of the year-long task, and 30% of the work still had to be completed.

Take or refuse?

Such situations in the development market are not uncommon. All because of basic mistakes in planning (we talked about this in another article, which can be found on the blog).

Finding himself in such a situation, John asked for help, because in case of failure he faced heavy fines since the customer company is a large enterprise. After conducting a preliminary assessment, our team assessed the starting conditions and came to the conclusion that to finish the project in 3-4 weeks, one of which will be spent on coordination with the client, the collection and onboarding of the team is a very big risk. Risky, but, as our PM said, it is not impossible. The system was written by a different team, the available documentation was in chaos, and there is no direct communication with the client – all of these reduces the chances of closing it on time, and our team tries not to take on the project if it cannot guarantee successful completion.

Even realizing the likelihood of failure, John asked to take on the project, since the professional team was his straw. In this case, it was better to try something than to do nothing at all.

Like any customer, John was worried about what the budget would be, and what would be needed, and asked for estimates for completion. There was no time to make an estimate in such conditions, and the work was carried out in the support mode and research with “gestures”. All for the sake of minimal planning, with the transition to further full-fledged analysis.

To give an estimate, it was necessary to understand the project, to understand all the functionality, modules, and a complex data structure, to conduct an assessment, and there was simply no time for it. As a result, we calculated the budget based on the number of people in the team and the number of weeks before the deadline.

Now there was a new problem.

How to beat time? Gather a good team

In such situations, without a good team, as without hands. In the literal sense of the word. When work on the system started, a huge number of problems emerged, ranging from lack of documentation to lack of staging, unstructured code, and an absolute break in communication.

In fact, the problem was much more global than can be described. Due to the fact that the code was written by many developers, while everyone wrote as he wanted, there were simply an uncountable number of bugs not fixed in the tracking system. The functionality was isolated within a certain page, there was one thing in the mockups, but in reality something else.

Despite the enterprise level, there was no documentation, not even the design of the system. To say that difficulties arose because of this is to say nothing. Even the same button was implemented differently in different parts. There is even nothing to say about testing, no one has done this a priori.

There was a lot of work, so we rolled up our sleeves and got down to business.

What was done?

To ensure minimal planning, we switched to Scrum with short sprints. Organized dev, demo, test, and production development environments, and implemented CI / CD.

Since the transfer of knowledge on the technical organization of the project and the business component was carried out in the development process, the following decisions were made:

Planning

Estimation of tasks by the developers was made on the basis of their previous experience in developing such systems without being tied to the existing code.

The resulting estimates were modified by coefficients related to the developer’s current level of boarding in the project and the individual performance of each developer.

We have simplified the estimate approval system: everything that was less than 4 hours was done without confirmation.

Testing

The final testing and preliminary analysis were taken to the client’s side since we could not fully accept the project in such a short time.

Systematization of development

To get quick results, the development was initially carried out without changing the architecture and refactoring. In parallel, an analysis and description of the architecture were carried out, a system of requirements was organized and a list of technical debt was formed.

After 4 weeks …

All planned tasks were completed on time, the system was stabilized, and the team was assembled and onbordered. In addition, the foundations were laid for the further systematic development of the project. The guys worked overtime and did the simply impossible, especially considering all the difficulties in development, which only increased the term of work. But in the end, the team backed up what John promised the client by the end of development.

In this case, the PM did a great job of team building. The guys were from different teams, and it was very important to create an atmosphere for productive work. As a result, the whole team was ready to work overtime.

The customer liked the project, and after it came the next proposal for cooperation at a more relaxed pace.