We manage a big long project: why is it important to speak with words

I was subordinate to one project manager who never called meetings. He was a bit hikki and possessed exceptional perfectionism (as far as possible for PMA ), which was expressed in an effort to fix everything in the mail. The letters were very detailed, on several pages: they contained all the necessary descriptions, they contained all the promises, deadlines, wishes, great attention was paid to agreements and reproaches of the irresponsibility of the performers. In general, the ideal letters that consistently set out the course of events - even write a book on them.

But the project went slowly: you must write letters, then wait for an answer and write again. Since it was long, it was vividly visible, as in the third month delays and technical debt began to accumulate. My colleague continued to write letters, fixing every commitment and every joint and postponing the deadlines regularly. The situation is tense.
')
I regularly asked him to collect team leaders for the project (iron engineers, developers, and so on). Based on my experience, the problem most likely was that the teams did not change the information between themselves.

He gathered a meeting, but was silent on it. And everyone was silent. More precisely, they reported statuses and raised issues. The result of the meeting - he wrote another long letter with the requirements and fixation of statuses with jambs.

Delays continued to accumulate.

I ask why he does that. He: "I want traces left in the mail." By the time of the showdown, when the project will be disrupted, so that everyone knows how it happened. Everything is clear for him, at what point which performers violated what obligations.

In the end, I had to remove him from this project and put a new PMA with experience of “long runs” and the need to communicate. The old project manager left the company, he managed to find himself in short projects for a month or two, where it is just the most important thing to clearly formulate requirements. In the long projects, however, a lot of things are changing and moving, so any plan collapses. And the task of the project manager is to make it all move. And a very important skill is to ensure the exchange of information between all participants and build relationships.

This is directly critical for large projects.

Communications management

One of the competencies of a good PMA is communication management. This is the official name of the situation when everyone knows what is happening and why you need his piece of work. And what it affects. It may seem that the ordinary linear engineer does not need such knowledge, and the usual linear developer must write code, but in reality all this is important and directly affects the project. Because together with the knowledge of movement, meaning, emotions are transmitted and various unexpected people are discussed. And any project largely consists of unexpected and friction between the teams. If everyone were telepaths, we would have grown apples on Mars.

The second illustration: I find out about the project, where in half a year everything has to be put in time, and the work at the site has stopped and is not going. It turns out that there we have been coordinating estimates for additional work for several months, all clearly according to the procedures of the customer. The team is confident that we will get the money and then we will start working. PM says: it’s difficult, we got into someone else’s competition, project documentation isn’t good, they don’t like us, the seller, we didn’t have to sign this contract. ” I go to the sales manager, who is responsible for communication with the customer. He says: “Why have you not fired this RP yet? Nothing moves, I am ashamed in front of the customer. ” And almost immediately from the customer comes the claim instead of agreeing the estimates - they say, let's pay penalties, and then we will agree on how you will finish.

The project was set PMA with experience building relationships. Establishment of communications with the new head began with the legal department - it was necessary. The story was that the customer formally communicates, does not want to see us as a contractor, and we do not notice the trick, we naively wait for the money, and no one is going to pay money from that side. As a result, synchronized data about the project for a couple of large meetings and completed it. Profit was, but much less than expected.

Why is it important to collect these damn meetings?

Three reasons: a wide channel, preparation for a meeting and shorter iterations. Mail does not give the opportunity to respond instantly. Usually the answer comes on the same business day or the next. It is possible to shorten the timing of iterations with project chats or messengers, which will significantly change the speed of various approvals and discussions, and this is a very good practice.

But our hickey would not have saved it, because it is only half the battle. The second half is to make the teams change information across a wide channel, that is, not only within the constrained minimum need, but a little more, with the entire background. This background includes emotions, priorities, tasks and much more, but the main thing is a lot of details that allow everyone to understand what to do and how. Practice shows that this is important for the course of any long project. Actually, all methodologies like Agile / SCRUM / Holacratia and so on - they are just about that.

Minimal iterations and constant exchange of information. Actually, if we do not have a development and the team is not sitting in the same room, then the meeting is, in fact, the only opportunity for the project manager to motivate the team and individual participants for the result, to remove all the contrived and obvious obstacles and excuses of the performers on the way to the result. Again, because of the wide channel.

Here is a vivid example of how it happens when the exchange of information is pressed into the minimum channel. We had a project - the head prepared a plan, agreed with all the participants from us and sent it to the customer. In order not to get that the customer does not know what is happening. Every week reports. According to this plan, he reported. Everything seems normal. Thought everything was fine. We went to the meeting in three weeks. We come and say: they say, how do you like everything? And here they take and get their plan. It turns out that they have completely different wishes on the order and what to do. Ours they did not even look. They didn’t want to write about it, because it seems that work is going on, everything is fine. But it is not clear. And when it is not clear, in some places it is inconvenient to say "I did not understand." Or just laziness. Or just everything is okay, well, do not touch. And only in oral communication we managed to understand that we see everything differently. They went according to their plan, interaction went, problems, questions, discussions and solutions appeared. Every week we understood that we were doing what we needed, and the customer participates in this.

This is also very important.



The task of the PM is the exchange of information, so that the engineers know what they are doing and who they are reporting about; the customer knew what was going on, when to expect results and what the results would be; the architect knew about the limitations, how to design and with whom to communicate. Everyone has a lot of questions. One of the methods is status meetings. Tell what has been done for the week and what is planned in the near future. In principle, it is possible and not to do it - you can report not weekly, but when there will be results, depending on the intensity and amount of work on the project, or you can respond. It depends on what decision the PM will take - either to each letter, or to everyone once, or ring up, or call to the crowd. Our usual practice is a status meeting. Because one also has to prepare for it, which, moreover, allows the person to get together, find all the necessary information, share with the team, and not let something drift.

And, of course, it is much easier and quicker to formulate something orally, because not all people can express their thoughts in writing absolutely freely. A status meeting is just one hour per week for one project. Minimum of time, no spoiled information from third-party hands, parties, rumors, interpretations, guesses and re-discussion of previously taken, but not properly made public decisions. The project manager conveys and records information, and participants only listen, understand and ask clarifying questions.

If you do not do this, we are waiting for a system alteration. The seller wants to know where the team is going. The customer issues comments to different people - if he is not told. Who will catch, and that will express. When a remark comes to engineers from different people from different sides, they are dissatisfied, and conflicts will begin immediately when there is no common vision.

When to work on a project?

Here is a plan for one of the projects:


As you can see, this scheme provides synchronization of information for everyone on the project. But at the same time she is very demanding on the resources of key people. On Monday, the day turns out to be broken by one meeting (and we must prepare for it), on Tuesday, too.

These costs must be tolerated. In order to minimize their impact on the project, each time you need to choose the minimum possible number of participants. For example, an architect does not drag engineers along with him, the Timlides convey information to the teams themselves, and so on.

The second question is whether such frequent exchange of information with the customer provokes changes in the TK? Provokes. If TK was poorly formulated, it will change more often. And this is good, because the goal is to do what is necessary, and not what was ordered and formulated. The sooner the need for change is discovered, the cheaper and faster it is implemented. It is an extremely rare case on projects where TK is immediately good and you just need to do it with someone’s hands. Then there will be a minimum of changes, then the leadership style will go through the letters described above, but only if the team is motivated for the result, and this is a great rarity in our realities, when we do not run falcons. And very rarely the customer wants to do the TK, and not as it should, it is rather the area of ​​legally complex projects. Usually the task is to make the project fit. But my colleague wrote about it well in a post about what the project manager does .