Burning Deadline: How the Project Manager Can't Get Lost

Everyone knows what a deadline is, but not everyone knows how to set it correctly. To talk about breaking the deadline on the project, you can pick up many beautiful metaphors. Yubitsume is one such. This is a ritual cutting of the finger phalanx in Japan. In particular, they resort to yubitsume to apologize to the leader or owner for a mistake. If you watched films about the yakuza, then you understood what it was about.

The ritual went from among the Bakuto gambling community, and was seen as an adequate substitute for paying the debt. The debtor allowed the little phalanx to be consumed, and this complicated his further life: he could no longer hold his sword securely and in battle was more dependent on his companions, including the owner.

It doesn’t matter what time and place you live and what you do - team relationships must be strong, and deadlines must be respected. The managers of Live Typing Studio, although they don’t cut their fingers off, are still responsible for the word given to the client. Experience has allowed me to formulate six errors, making which, you definitely risk losing the job on time, and what to do to comply with deadlines. Having ceased to make these mistakes, you will notice how the quality of your projects will increase, how much time will be freed up for rest and how relations between team members and with the client will improve.

You do not know with whom you work

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 the project, but lacks perseverance and concentration, and someone appreciates the time that the task will take. From the latter, timlids are obtained, which are usually good at everything.

With all these, so different, people need to work in a different style. Some need incentive, whether it be tight control or encouraging words; others expect you to tell them about the client background, his ideals and outlook on life, what he expects from the team and how he relies on it; still others just work. If you do not make allowances for the character of a member of your team, he will be left to his own devices and his worst habits, and the deadline will probably be disrupted.

No less important is the experience of a specialist. Distribute tasks according to their abilities and coefficient of productivity, otherwise the June or Middle will fail a task that they can’t initially do.

You did not understand the objectives of the project

Work on a website or application begins with the design phase . This is a serious stage: it remains to be seen who will use the product, what goals it is intended to achieve, 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 formulating tasks for designers and developers.

The functionality of the application should have a clear purpose. If the manager did not understand it, this means that the design is poorly done, and the task will not be set correctly for the contractor. The result is unpredictable, because the developer can begin to think up the role of functionality, inflate it, and eventually spend a lot of time writing and rewriting code.

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

The more accurate and complete the documentation is, the less developers will have misunderstandings and bugs during development, which ensures compliance with deadlines.

Your team members incorrectly rated tasks

An incorrect rating is the cause of most burnt deadlines. Each case of an incorrect assessment should be discussed in retrospect, find the reasons and develop tactics to address them in the future.

Some juniors and middles tend to overestimate their strengths. With experience, a good manager begins to understand this and makes adjustments: for example, after hearing an estimate of 10 hours, he multiplies it by 2 and gets a result that later turns out to be more true.

A senior developer is not one who is older than the rest, but who knows that it may take more time to complete a task than expected, and 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 are all that you did not plan and which will slow down work on tasks. They are external and internal. The disconnection of the Internet, a hurricane or a flood, a change in the requirements for a product - these are external reasons that artists cannot influence in any way. A long search for a solution to a problem, a nervous breakdown at the developer - these are internal causes and they can be controlled.

You can reduce the likelihood of risks due to decomposition, or splitting a large task into small ones. 40 hours is not always four tasks of 10 hours each; during decomposition, it may turn out that for integration of a painfully familiar payment system into an unfamiliar project, ready-made box solutions will not be enough, and you will have to write your own. Decomposition will help to correctly evaluate the deadlines and simplify control over their observance.

Some of the external causes can also be influenced, especially when they lie in the client. The sooner the client gives access to texts, logo, documentation, API (in case the server side does the command on the client side), the better. And it will be even better if you collect 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 easily. Inform him about the status of the tasks, talk about everything that can go wrong and that will lead to delay, talk about what you are trying to solve the problem. Firstly, you may be surprised at how it brings you closer and encourages you to engage in the most constructive dialogue possible. Secondly, a possible exit for the term and its reassignment will no longer be a surprise for the client. Good communication is the key to success .

You have no plan B

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

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

You cannot add value to the client in the eyes of the client.

Still, starting with an apology is normal, this is basic politeness. Another thing is that apologies need to be supported by something applied. It will 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 the deadline made sense for the project in the future. For these extra 16 hours, you probably scrupulously tested the application and fixed bugs that would irreparably ruin the product and the client’s image if it fell into the hands of the user.
  

If you do not want to feel guilty and make a malfunction 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 specifics of your work leads to other errors. It will be great if you talk about them in the comments.