We manage a large long project: why it is important to speak in words
I had one project manager in my subordination who never convened meetings. He was a little hickey and possessed exceptional perfectionism (as far as possible for PMa ), which was expressed in the desire to record everything that was happening in the mail. The letters were very detailed, on several pages: they contained all the necessary descriptions, they contained all the promises, deadlines, Wishlist, much attention was paid to the agreements and accusations of irresponsibility of the performers. In general, ideal letters consistently setting out the course of events — at least write a book on them.
But the project went slowly: you have to write letters, then wait for an answer and write again. Since it was long, it was clearly visible how delays and technical debt began to accumulate in the third month. My colleague continued to write letters, fixing every commitment and every school and regularly rescheduled. The situation was heating up.
I regularly asked him to gather the leaders of the teams working on the project (hardware engineers, developers, and so on). Based on my experience, the problem was most likely that the teams did not change information among themselves.
He gathered a meeting, but was silent at it. And everyone was silent. More precisely, they reported statuses and raised problems. The result of the meeting - he wrote another long letter with requirements and fixing statuses with jambs.
The delays continued to pile up.
I ask why he does this. 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 with him, at what moment which executors violated what obligations.
In the end, I had to remove it from this project and put in a new PM with experience of “long runs” and a need for communication. The old project manager left the company, he managed to find himself in short projects for a month or two, where the most important thing is to clearly state the requirements. In long projects, 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.
One of the competencies of a good PM is communication management. This is the official name for the situation where everyone knows what is happening and why his piece of work is needed. And what does it affect. It may seem that the ordinary linear engineer does not need such knowledge, and the ordinary linear developer should write the code, but in reality all this is important and directly affects the project. Because along with knowledge about the movement, meaning, emotions are transmitted and various unexpected people are discussed. And any project in many respects consists of unexpected people and friction between teams. If everyone were telepaths, we would already grow apple trees on Mars.
Second illustration: I will learn about the project, where everything should be delivered by the deadlines for half a year, but work on the site has stopped and is not going. It turns out that there we negotiate estimates for additional work for several months, all clearly according to the customer's procedures. The team is fully confident that we will receive the money and then we will begin to work. PM says: it’s difficult, we got into someone else’s competition, the project documentation is not good, they don’t like us, the seller, it was not necessary to sign this agreement. ” I go to the sales manager, who is responsible for communicating with the customer. He says: “Why haven’t you fired this RP yet? Nothing moves, I am ashamed of the customer. " And almost immediately a claim comes from the customer instead of agreeing on estimates - they say, let's pay penalties, and then we will agree on how you will finish it.
PMa with experience in building relationships was put on the project. Communications with the new leader began with the legal department - had to. The story was that the customer formally communicates, does not want to see us as a contractor, but we don’t notice the catch, we naively wait for the money, and no one is going to pay money from that side. As a result, the project data was synchronized on a couple of big meetings and completed. There was a profit, but much less than expected.
Why is it important to gather these damn meetings?
Three reasons: wide channel, preparation for the meeting, and shorter iterations. Mail does not give an opportunity to respond instantly. Usually the answer comes on the same business day or the next. You can reduce the iteration time with project chats or instant messengers, which will significantly change the speed of various approvals and discussions, and this is a very good practice.
But this would not save our hickey, because it was only half the battle. The second half is to make the teams exchange information over a wide channel, that is, not only within the framework of the compelled minimum need, but also a little more, with the whole 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 the methodologies like Agile / SCRUM / Holacratia and so on - they are just about that.
Minimal iteration and constant exchange of information. Actually, if we do not have 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 on the result, remove all far-fetched and obvious obstacles and excuses of the performers on the way to the result. Again, due to the wide channel.
Here is a striking example of what happens when the exchange of information is pressed into a minimal channel. We had a project - the manager prepared a plan, agreed with all participants from us and sent it to the customer. So that it doesn’t work out that the customer is not aware of what is happening. Every week reports. According to this plan, he reported. Everything seems to be normal. I thought that everything was fine. We went to the meeting three weeks later. We come and say: they say, how do you like everything? And then they take and get their plan. It turns out that they have completely different wishes regarding the order and what to do. They didn’t even look ours. They didn’t want to write about it, because it’s like 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 okay, well, don’t touch it. And only in oral communication was it possible to understand that we see everything differently. We went according to their plan, interaction began, problems, questions, discussions and solutions appeared. Every week we understood that we were doing what was needed, and the customer was participating in this.
This is also very important.
The task of PM is to exchange information so that engineers know what they are doing and to whom to report; the customer knew what happens when to expect results and what the results will be; the architect knew about the limitations of what 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 in a week and what is planned in the near future. In principle, it can not be done - it is possible to report not weekly, but when there will be results, depending on the intensity and volume of work on the project, or you can call back. It depends on what decision the PM will make - either to each letter, or to all once, or to ring up, or to call the crowd. Our usual practice is a status meeting. Because you also need to prepare for it, which, in addition, allows a person to get together, find all the necessary information,
Well, of course, verbally it is much easier and faster to formulate something, because not all people can express their thoughts in writing absolutely freely. A status meeting is only one hour per week for one project. Minimum time, no spoiled third-party information, interlovers, rumors, interpretations, guesses and re-discussion of previously adopted, but not duly promulgated decisions. The project manager communicates and captures information, and participants only listen, understand and ask clarifying questions.
If you don’t do this, we are waiting for a system alteration. The seller wants to know where the team is moving. The customer gives comments to different people - if he is not told. Whoever catches, he will express it. When engineers receive a comment from different people from different sides, they are unhappy, 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, it is very demanding on the resources of key people. On Monday, the day is defeated in one meeting (and you need to prepare for it), on Tuesday, too.
You have to put up with these costs. 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 carry engineers along, team leaders convey information to teams themselves, and so on.
The second question is whether such a frequent exchange of information with the customer provokes changes in TK? Provokes. If TK was poorly worded, it will change more often. And this is good, because the goal is to do what is needed, and not what was ordered and formulated. The sooner the need for change is discovered, the cheaper and faster it will be realized. An extremely rare case on projects where TK is immediately good and you just need to do it with someone else’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 by the result, and this is very rare in our realities when we do not launch Falcons. And it is extremely rare that the customer wants to do it according to the ToR, and not as it should - it is rather an area of legally complex projects. Usually the task is to make the project fit.what the project manager does .