We solve standard problems for PM on projects. Part 1

About what? And for whom?

Did you encounter a situation where a client increases the amount of work for your team, although his demand, in general, is suitable for TK?

Happened that the development is delayed, but not the fault of your team?
')
How should act in such situations? What to do if the development is delayed, although everything goes the way you originally planned together with the client? And for the client you do not have an objective answer to this question, except for the standard reason: “the task turned out to be bigger than we thought”.

In the article I will describe what needs to be done first of all in a given situation and what should not be forgotten.

A warning

I just want to warn you that we are not working on any of the Agile frameworks, but we use a large number of Agile practices that fit our processes. Therefore, you will not see terms like “sprint” or “story point” in the article. I think that the presented instructions are where to expand, but at the same time they can be the basis and help the work of the manager.

The development process slows down due to circumstances that do not depend on you (third-party developers / lack of data from the client).

Suppose that the person on whom the delay depends is already notified, you feel weak progress on your issue and you need to do something.

1. It is necessary to understand at what point this situation will begin to affect the development timeline.
   
   If you have a spare time, you need to clearly evaluate it. And it is important not to miss this moment, because not always all the cards are on hand. Something needs to be learned from your team or management, and the result may be unexpected.
   
   
2. Take away the buffer from the received dates and report in the letter about the problem. The letter must specify the terms and consequences. This letter should be written formally and emphasize the seriousness of the specified facts.
   
   This action will be a warning shot in the air. It can be repeated several times, but only if the deadlines are safe.
   
   
3. In a situation where the deadlines are coming to an end, you need to write another letter. It is necessary to notify all people from the client and third parties, if they relate to this situation, by e-mail, putting a copy of all the actors (the letter in which the more managers in the copy, the faster the issue will be resolved). In the letter, it is important to point out that delays will directly affect the deadlines and shift the responsibility for this to the responsible persons.
   
   This step should be a very serious help for people dragging out the process. You also maintain professional ethics and make a direct shot after a few cautious ones only at those people who delay the process.
   
   
4. The previous step is the starting point. Usually, high management solves your problem quickly enough, but if in a short time you realize that the deadline from point 1 is in danger, then you need to look for compromises with your team. And to propose solutions to this problem in an official letter, in a copy of which will be people from the 3rd paragraph.
   
   So you show that you are always ready to solve the problem and compromise if necessary. Plus, everyone up to the top management will see your responsibility and professionalism as an artist.
   
   
5. Further actions vary greatly depending on the nature of the compromise and are worthy of separate instructions.
   
   In all this instruction, I do not describe possible meetings or calls to persons involved in the case, because all the necessary information is indicated in the letters and voice duplication is necessary depending on the specific situation. Letters are practically documents, so I will focus on them.
   

For experienced

For experienced managers, such instructions may seem trivial, but ...

Each project has its own emotional background and different circumstances that can be confusing and it will seem that the situation is unique. Although in fact it never hurts to move according to an instruction approved, even if it is before itself.

For newbies

An inexperienced manager often thinks that many situations are unique and have never happened to anyone. But after reading the instructions, associations often arise in the head, similar working situations and an awareness of their repetition comes.

For all

In general, the idea of ​​instructions appeared with one simple goal - not to reinvent the wheel every day, but to fix a set of certain actions and save “heavy fuel” (if you understand what I mean).

The client asks to do the work is not planned by you (out of assessment), but suitable for TK.

1. Make sure that it is really necessary for the client. Learn the priority in relation to other project fitsy. In some cases, tell the client that this functionality was not planned, but this can be done by cutting the other.
   
   You can find out what the client is asking, he plans to do as part of the next contract, and not now. Talking to the client that such functionality was not planned, it is necessary with full confidence. It is important to just remember that there is such an option and the sooner it is used, the more effective it will work.
   
   
2. What needs to be done after we understand that this has to be done for sure, but we do not have an exact understanding? It is better to request this functionality in writing, ideally with examples. Also immediately discuss the possible lightweight versions of this functionality.
   
   Perhaps the client means what you are going to do and you just do not understand each other. As you understand in the 1st and 2nd stage, we are trying to understand whether we really have to change our development plans.
   
   
3. Start the process of revising the project's scop in the context of changing functionality without changing the budget
   
   I singled it out as a separate instruction, because you can eventually reach it in completely different ways.
   

The sweetest

I am sure that with the process of optimizing the budget I met every PEM that worked on a fixed price project. I tried to combine the generally accepted actions in this situation in one list. But besides actions, I think that it is necessary to pay attention to accents and trivia, which it is important not to forget during the stages.

The process of revising the scopa project in terms of changing functionality without changing the budget

1. Clearly understand the priority of Fitch in relation to the rest and the risks of its creation.
   
   We need to understand how to rebuild the original product creation plan to realize how hastily you need to change everything . Determining the risks is necessary in this case, because the higher the risks in the new fitch, the earlier it is worth undertaking.
   
   
2. If possible, prepare a version of the outcome for the customer without loss of product quality.
   
   The meaning of the item is quite simple, if the client took advantage of the specifications in their favor, then you obviously can also . In this situation, it is better to start a review of the scop below the priorities of the fitch. What questions should I ask myself when searching?
   
   What can be simplified from the non-priority part of a product for a potential user?
   Can make those fitchies in which big enough risks are incorporated, and try to win there a part of the budget?
   
   It is important not to deduct from the budget testing, refactoring, review and. etc. - these are important project processes!
   
   At the exit from this point, ideally, there is an option in which the product does not change with respect to the solution of the main tasks of the client and regarding specifications.
   
   
3. Get from the team options for compressing functionality with a new one, with emphasis in compression on non-priority functionality. Determine whether the new functionality is fatal in terms of project budgeting.
   
   We turn to this point if we understand that it will not be possible to solve the client’s problem without changing the initial specifications. Questions are asked the same as the last paragraph.
   
   What should happen at the exit? A very profitable offer for the client , in which, when exchanging a new functional for a lower priority, he will receive a product that is cooler than what was originally planned.
   
   If you understand that the changes are fatal , that is, you need to change too much and the output will be a completely different product, you need to take it for yourself first, and then explain the whole situation to the client, ideally at a meeting with an unlimited time limit discussion.
   
   
4. Inform the client that at the time of the negotiations, development may slow down due to the removal of some functionality from the list of mandatory works. Suspend work on a project if necessary.
   
   After the meeting, summing up its results, it is better to duplicate the above written information to the client in a letter. By this you focus attention on this and can speed up the decision making on further development.
   
   
   
5. In a situation where the new functionality is fatal in terms of budgeting, inform the client about it. Offer solutions (for example, increase the budget). If the functionality is not fatal, suggest options that the team has put together.
   In difficult situations it is better not to be limited to correspondence and calls, but to appoint a rally.
   
   
6. The next steps should be rescheduling work according to new requirements and a smooth continuation of the project.

What happened?

I understand that the text can be perceived as a mixture of instructions and internal company regulations. But in any case, the work of managers consists of standard and non-standard tasks and, in my opinion, if you learn how to solve standard problems quickly and simply, you can save a lot of time for truly non-trivial work and get many times more useful experience.