Protocol in project management - unnecessary bureaucracy or necessity?

The meeting is one of the main communication tools on projects. This tool is not always used correctly. In particular, in the course of our work, we often hear that drawing up a protocol is a breeding of unnecessary formalism. "While we are writing protocols here, the work is worthwhile!", "We are creating bureaucracy, but there is no time to work" - I am sure that most of those who participated and are participating in project management have heard something like this many times. Moreover, such words are heard both in small projects and in large-scale projects and megaprojects.

This is especially true for internal work meetings. "Colleagues, well, we understood everything here. Or is something unclear to someone?" - after such a message, especially from a high-ranking leader, the participants usually have no questions...

In the worst case scenario, after such a meeting everyone disperses and continues to do their work, setting their own priorities. And if participants have the opinion that "everyone already knows what to do," in most cases this opinion is false.

Several times, having been invited to conduct project checkups, some time after meetings without minutes, we asked the participants what instructions they received as a result of the meeting, and what they expected from others. There was not a single case where the answers coincided - everyone preferred to understand what happened in a way that was beneficial to them. It is not difficult to guess that such work did not provide either systematicity or a normal level of interaction.

We also observed cases of mutual insults between employees who are structurally not subordinate to each other: "We agreed 2 months ago that you would do this!" - "This is not what we agreed on!" This work situation led to interpersonal conflicts.

There are often cases when the protocol is drawn up formally - instructions are formulated as slogans ("ensure", "accelerate", "catch up", etc.), deadlines for implementation are not fixed, and subsequently no one monitors the execution of these instructions.

Sometimes managers deliberately do not record instructions, thus masking their inability to organize work. After all, later they can arrange "carpet" dressing downs, accusing the entire team of "bad work".

The opposite situation is that following a meeting, a protocol with dozens of instructions is agreed upon over a long period of time. The value of such a protocol is greatly eroded. It is impossible to regularly monitor the execution of such a number of orders. I've seen how, during a weekly meeting on the status of execution of project orders, out of 80 unfulfilled orders, no more than ten managed to be reviewed, writing an abstract wording like "ensure that orders No. 11-80 are completed on time" in the next minutes.

No matter how difficult it may be for many project participants who are accustomed to working "hurriedly" or relying on verbal agreements, the protocol is the most important, integral part of the communication process. Its regular, correct use allows you to record instructions in wording that does not allow interpretation, as well as track the execution of instructions, promptly learning about potential delays and responding to them. In a correctly drawn up protocol, in addition to a clear wording of the assignment, those responsible and the deadline for completion must be indicated, which minimizes the likelihood of misunderstandings and the possibility of "pretending to misunderstand." For project management processes, a protocol is a tool no less important than, for example, a schedule network model or a project status report.

It is not necessary to make a printed protocol with live signatures - within the team, as part of the internal methodology, you can agree on a short protocol in electronic correspondence. Clear agreements and discipline are much more important than a specific document format.

A mandatory integral part of the control of orders is a journal where orders from the protocols are entered, indicating those responsible, deadlines for execution and links to the result. Typically responsible for maintaining and updating the order control log project administrator or department administrator. Some of the orders from the control log can be included in the schedule network model of the project in the form of work.

The absence of a protocol and a journal with recorded instructions allows the performers to evade responsibility. Possible collective responsibility (more precisely, collective irresponsibility), when the manager simply swears at everyone for bad work, as a rule, does not bring the project closer to success, and does not add authority to the manager.

It is safe to say that the protocol is a necessary project management tool that must be correctly applied throughout the project life cycle. And its correct use is possible only if the participants fully understand the purpose and benefits of this management tool.