Why is Project Management Considered to be a Bureaucracy?
We’ve already talked about why project managers don’t like project management. Serious additional workload appeared as one of the reasons for the negative attitude. Indeed, the project manager has to spend time preparing and managing the approval of documents, communicating with customers and project participants, and following the regulations adopted by the company. And if, in his opinion, the requirements for project management in the company are unrealistic and harmful, the manager will be very reluctant to follow these procedures or even begin to sabotage them.
In this article, I propose to consider anti-patterns — negative manifestations in the content of the requirements of the project methodology or in the order of its application, which allow project managers to conclude that the project management system in the company is bureaucratic and, therefore, ineffective.
Document Content Issues
1)Information not used. It happens that the controlling structures regularly request documents, the information from which is not analyzed and does not benefit the project or the company. In this case, the project manager does not understand the usefulness of these documents and therefore does not want to spend time on them.
Example Situation 1. Every month, the project manager prepares timesheets for the project. However, this information is not discussed at meetings and does not affect the adjustment of schedule, evaluation of the effectiveness of a manager or a team, and allocation of additional resources, if necessary.
Example Situation 2. There is a log of issues that occur in the project, and it needs to be filled out regularly. In general, keeping such a log is very useful: it allows you to identify problems promptly and respond to them. But if the matter is approached formally and, the problems themselves are not discussed by anyone, no specific actions are taken, then it is pointless to waste time filling it out.
2) Information is being duplicated. Information may be repeated in different documents, or even in different sections of the same document, without any reaction.
Example Situation. The project passport in the company contains the sections “Project Objectives”, “Project Justification”, and “Project Benefits”. When filling out the passport in the “Justification” and the “Benefits” they copy and paste the information from the “Goals” section, and in this form, the document is approved. In this case, it is not clear why the document should be bloated into three sections when one can be limited. At the same time, documents in this form do not raise questions and are successfully approved.
3)Inadequacy of the requirements to the risks. If the risk management procedures are inadequate for the risks they are supposed to prevent, then the time spent will be incomparably extensive.
Example Situation. In a company with an extensive portfolio of IT projects, every project, even a typical one from an architectural point of view, is carried out through an architectural committee. Accordingly, the projects are waiting, plus additional time is spent preparing for the meetings.
4)Form matters more than content. The unification of the document format allows you to quickly track down when something goes wrong. This allows management to save time in preparing, updating, and reviewing the document. But when the comments primarily concern the design (fonts, text alignment, filling specific cells in the table), and the unclear or conflicting information contained in the document is ignored and not commented on in any way, then the check is of a formal nature, and the form prevails over the essence.
Approval Procedure Issues
1)The duration of change approval is comparable to their pace. As a result of external changes in the business or because the initial stakeholder expectations were not clearly articulated, a change request can arise in any project. This allows you to adjust the main parameters of the project (goals, budget, deadlines), taking into account the changed or updated data. A change request can be approved, rejected, or amended. But if during the consideration of the request, the data has lost its relevance, then the approved plan will also turn out to be irrelevant, and the change that has occurred will have to be accepted as a fait accompli, and the process of refining the project parameters will have to be started again.
2)The approval procedure blocks all project work. In some cases, a ban on any action in the project until all formalities are agreed upon is justified. For example, you should not start working on a client project until the contract is signed, even if verbal agreements with the customer have already been reached. But in some cases, you can use the post-control mode — for example, using reporting, that is, checking what has already been done and not stopping work until all approvals are received.
Example Situation. According to the company’s regulations, the resources of contractors can be attracted to the project only after it is thoroughly planned. But planning also requires resources. It turns out that the inability to attract qualified resources blocks the prospect of qualitatively planning the project and moving on to its implementation. To avoid this situation, you can introduce the possibility of purchasing resources in a small amount in the early stages of the project.
3)It takes a long time for decisions to be made. Issues related to the allocation of contractor resources and the approval of new initiatives are resolved only in a strictly allotted time. For example, you have to wait for the meetings of the project committee, which take place once a quarter. Or, to request resources, an application must be submitted no later than two months before the meeting. In such situations, it is easier for the project manager to obtain resources from other sources or abandon the project and, in no case, initiate it himself.
4)Non-transparent and non-standardized approval procedure. If there are no clear criteria for evaluating project documents and clearly defined deadlines for approval, the project manager does not have a complete picture of what and how he needs to do to approve them. At the time of approval, requirements may arise that were not previously mentioned in any documents or conversations. The number of iterations will grow, and the requirements will change unpredictably. As a result, there may be a feeling that the approval process has nothing to do with the work done and depends only on external factors — for example, on the mood of the management.
5)Inappropriate specialists are responsible for the approval. If the approval process is tied to people who do not understand the project’s content or are not interested in the results of the project as a whole, then it can be delayed or even run into outright sabotage. The presence of such a procedure can block all work on the project.
Example Situation: In the company, all project documents, regardless of their uniqueness, purpose, or risks, must go through the legal department. Lawyers disagree on the project charter, referring to the inconsistency with some clauses of the Civil Code. As a result, the charter is being negotiated throughout the entire project and does not solve the assigned tasks.
6)An overloaded person is responsible for approval. If the company does not have enough resources (for example, in the area of information security) and one employee has to coordinate the data of all projects, or the approval process is not the main task for him, then the “bottleneck” effect occurs — all projects get stuck at the approval stage in one place. In addition, project managers cannot count on help in this case if the area is new to them. Due to lack of time, the approval will be formal rather than substantive or helpful. In addition, often, after a long wait, a refusal follows, which lengthens the process even more.
7)The persons responsible for the coordination do not want to discuss the document. Sometimes, instead of entering into a lengthy correspondence with a specific service (lawyers, financiers, procurement division, project management office), it is easier to settle down controversial points and only then send the document for approval. But not all departments are enthusiastic about this practice, preferring to accept only written comments. As a result, this greatly complicates the process since the project manager must take the time to carefully work out all the comments and amendments. And if several iterations are required, then the process can stretch in time indefinitely.
Methodology Issues
1)Methodology irrelevance. Any organization is a living organism that is constantly changing. Internal rules, company structure, positions, powers, and degree of responsibility of employees may change. And with organizational changes, the project management methodology should also be reviewed. Otherwise, it ceases to reflect reality and only irritates project participants. If irrelevant positions are indicated in the methodology, if references to regulatory documents and the display of the company’s structure are outdated, then the methodology has to be disobeyed or constantly adapted to each specific case. In practice, it may turn out that a particular artifact does not work, and the requirements are not met, while the project management office continues to insist on compliance with all standards.
2)Exceptions become the norm. The world is not perfect, and it is impossible to foresee everything in the world. Therefore, in some projects, non-standard situations that require non-standard solutions may arise. In this case, it is possible to deviate from the procedures adopted by the company. But if such precedents occur regularly, this questions the necessity and usefulness of the methodology. “If it’s okay for someone to break the rules, then why shouldn’t I?” — sooner or later, project managers will begin to ask such a question. The presence of rules in such a situation will be perceived as a bureaucratic obstacle and not as a guide to action.
Thus, if the Organizational Project Management in the company is perceived by the project manager as bureaucratic, then the attitude to the procedures will be appropriate.
At best, the project manager will follow the requirements for project management formally; at worst, he will begin to sabotage processes and seek to avoid participation in projects. To prevent this from happening, it is worth regularly checking the management system for realism and relevance. Regularly check which documents or requirements are not being used (and therefore not helpful). Clearly formulate criteria for the quality of the processes. Monitor employee workload. And finally, do not forget to check the integrity and consistency of the methodology with changes within the company.
