Burning deadline: how the project manager won't lose his fingers

Everyone knows what deadline is, but not everyone knows how to set it correctly. To talk about disrupting the deadline on the project, you can pick up a lot of beautiful metaphors. Yubitsume - one of these. This is a ritual phalanx cut in Japan. In particular, to the jubicume resorted to apologize to the leader or owner for the mistake. If you watched movies about yakuza, then you understood what I was talking about.

The ritual went from among the bakuto players to gambling, and was considered an adequate substitute for debt repayment. The debtor allowed the little finger phalanx to be consumed, and this complicated his further life: he could no longer hold the sword securely and in battle he depended more on his companions, including his master.
')
No matter what time and place you live and what you do - the team relationship must be strong, and the timing must be respected. The managers of Live Tipping, though they do not cut off their fingers, are still responsible for the word given to the client. Experience allowed me to formulate six errors, by admitting which, you definitely risk failing the job at the wrong time, and what to do to keep deadlines. When you stop making these mistakes, you will notice how the quality of your projects will increase, how much time you will have to rest, and how relationships between team members and the client will improve.

You do not know who you work with

Each member of the development team is like a character in a role-playing game: someone has an abundance of ability to get involved in a project, but lacks assiduity and concentration, and someone well appreciates the time it will take to complete the task. Of the latter, tlmlids are obtained, which are usually good in everything.

With all these, so different, people need to work in a different style. Some need a stimulus, be it tight control or encouraging words; others are waiting for you to tell them about the client background, his ideals and views on life, what he expects from the team and how he hopes for it; others just work. If you do not make a correction for the nature of a member of your team, he will be left to himself and his worst habits, and the deadline for completing the task is likely to be broken.

No less important is the experience of a specialist. Distribute the tasks according to their abilities and performance factor, otherwise the jun or the middle will fail the task that they initially could not do.

You did not understand the objectives of the project

Work on a site or application begins with the design phase . The stage is serious: it is necessary to realize who will use the product, for what purposes it is intended and how it will bring money to its owner. The results of this stage are recorded in the functional task, and the functional task serves as the basis for the formulation of tasks for designers and developers.

The functionality of the application should have a clear purpose. If the manager does not understand him, it means that the design is done poorly, and it is impossible to correctly assign the task to the contractor. The result is unpredictable, because a developer can begin to think out the role of functionality, inflate it, and in the end spend a lot of time writing and rewriting code.

To avoid this, we conduct a design review: the entire team carefully and iteratively looks at the resulting prototype or design and finds as many gaps, errors, and missing screens as possible. High-quality execution of the design review greatly affects the timing.

The more accurate and more complete the documentation is, the less developers will have misunderstandings and bugs during development, which guarantees that deadlines will be respected.

Your team members incorrectly rated the tasks.

An incorrect rating is the cause of the majority of burned deadlines. Each case of an incorrect assessment needs to be discussed in retrospect, to find the reasons and to develop tactics for their elimination in the future.

Some juniors and midls tend to overestimate their strength. With experience, a good manager begins to understand this and makes adjustments: for example, having heard the estimate at 10 o'clock, he multiplies it by 2 and gets the result, which later turns out to be more true.

A senior developer is not one who is older than the others, but who knows that the time to complete a task can go longer than expected, and he boldly admits this to himself and the manager. A senior developer is aware of the risks, and you should. The following error is devoted to this.

You and your client are not aware of the risks.

Risks - this is all that you did not plan and that will slow down the work on the tasks. They are external and internal. Turning off the Internet, hurricane or flood, changing product requirements - these are external reasons that performers can not influence. A long search for a solution to the problem, a nervous breakdown at the developer is an internal cause and they can be controlled.

It is possible to reduce the likelihood of risks due to decomposition, or splitting a large task into small ones. 40 hours is not always four tasks for 10 hours; during decomposition, it may turn out that there is not enough ready-made boxed solutions to integrate a painfully familiar payment system into an unfamiliar project, and you have to write your own. Decomposition will help to properly assess the time and simplify control over their observance.

Some of the external causes can also be affected, especially when they are in the client. The earlier the client gives access to the texts, the logo, the documentation, the API (in case the server side does the command on the client side), the better. It would be even better if you put the risks associated with the client together and include them in the contract. This will be a great reminder to the client that he is also part of the project.

If the client is in good shape, then the project will go easy. Inform him about the status of the tasks, tell about everything that can go wrong and what will lead to a delay, tell about what you are trying to solve the problem. First of all, you may wonder how this will bring you closer and will push you to the most constructive dialogue. Secondly, the possible exit for the term and its reassignment will no longer be a surprise for the client. Competent communication is the key to success .

You have no plan B

A good manager, like a chess player, calculates the variants of events in advance. But if a chess player looks to the future only for a few minutes, then the manager - for a couple of months before the deadline for sure. During this time, all risks must crawl out.

In such a case, for a number of particularly difficult tasks, it is necessary to select a more budgetary variant of their solution, from which the user experience will not suffer, and the overall result will remain adequate. This is called flex. The option of the flex is to abandon the custom design A and still use the Apple and Google guidelines. Just do not forget to explain to the client that now is the best option in order to meet the deadline.

You cannot give value to the delay in the eyes of the client.

Starting with an apology is normal, this is basic courtesy. Another thing is that the apology must be supported by something applied. It would be great if you:

• analyze the problem at the meeting with the team, draw conclusions and promise the client that this will not happen again;
• justify that disrupting the deadline made sense for the project in the future. For these extra 16 hours, you probably scrupulously tested the application and eliminated bugs that would irreparably spoil the product and the client's image if it fell into the user's hands.
  

If you do not want to feel guilty and make a failure in the measured pace of your life, do not make any of these mistakes. I have listed the most basic ones and we think that the specific character of your work has other errors. It will be great if you tell about them in the comments.