Why don't Statutes and Project Management Plans work?
We come to the Customer and tell him: this is how we will plan the project, this is how we will manage the changes, this is how we will manage the risks, this is how we will hold meetings, this is how we will escalate problems and make decisions, these are the terms we will have for approval such a periodicity will be status meetings, etc. And we bring it to him in the form of a lengthy document like that for 30-50 regulatory texts. The customer looks at it with "eyes wide shut" and says: "Cool!". What does not correlate with the practice adopted by the Customer, he will propose to correct, but otherwise the document will be adopted.
And then life began and the processes went their own way, making decisions in their own way, and the document remained on the shelf. Sometimes the RP gets it to show that the Customer does not comply with the deadlines, or violates other agreements. But this is done when the project increases tension and the parties need to defend themselves. There are situations when the RP is trying to update the processes, but often they look at him “askew” as a bureaucrat who, instead of the result, deals with “pieces of paper”.
As a result, such a document fulfills the function of protecting an RPC or Contractor, or a marketing function for the Contractor: “Cool! You are working on project technology! ” And I would like the document to work.
First, let's understand the concepts. In the IT project industry, I often observe how two documents, the Articles of Association and the Project Management Plan are combined into one document, calling it the “Project Articles”. Probably, there is nothing terrible in this, especially when this “Charter” created at the beginning of the project is no longer used in the implementation of the project. But if you need to get working documents, you need to turn to the sources.
')
According to PMBoK: “The project charter is a document issued by the project initiator or sponsor who formally authorizes the existence of the project and gives the project manager the authority to use the organization’s resources in the project’s operations. It documents business needs, assumptions, limitations, understanding customer needs, high-level requirements, and a new product, service, or outcome that you plan to create. "" A project management plan is a document that describes how a project will be executed, how it will be implemented. monitoring and control. It integrates and consolidates all the support and base plans resulting from the planning processes. ”
So, the project charter is more static than the project management plan. He defines the essence of the project itself, it is an order from the Customer (or the Sponsor) to the Project Manager (hereinafter referred to as "RP"): it is necessary to make a project in such a specific framework. If it is necessary to change the fixed in the Charter, then for the RP or the Contractor it is a reason to revise the contractual relationship with the Customer. Accordingly, this document is made by the Customer or Sponsor, and not RP or the Contractor. It is important! We will not focus on the fact that the Project Management Plan is not a schedule, as some perceive it. Here, perhaps, affects the history of the use of the word "plan" in the Russian language. The project management plan talks about how the RP and the project team will execute and control this project to achieve results within the boundaries and parameters described in the Bylaws. This document is more dynamic, it is changeable in the course of the project, since it will not be possible to immediately identify all processes.
A project is a unique enterprise, and accordingly it has a unique set of processes. It is possible to assume at the beginning of the project, to plan some variants of the processes, but the project’s approach will reveal the nuances correcting them and this is normal. As Dwight Eisenhower said: “The plan is nothing, planning is everything. Any plan becomes outdated at the moment when you have completed its development. But in the planning process, you and your subordinates get one look at the situation and decision criteria, therefore, at the time of surprise, they will choose the right decision. ” Therefore, in the PMBoK process diagram, the project management plan is the output of several different processes, which is not the case with the project charter. Thus, the first reason for posting these two documents is their different purpose. The second reason is the dynamics of their changes. If you manage change, you will understand the importance of this reason. There is a third reason. At the time of project initiation, it is impossible to accurately determine how the project will be executed. After the appointment (with the help of the Charter) of the RP, it is necessary to form a team, define contractors, build the organizational structure of the project, decompose the content, think over effective processes. This can sometimes take months. Therefore, the Project Management Plan is born later than the Charter.
After you have understood the concepts, let's talk about why the Project Management Plans, which many people call “Charters”, do not work. I have seen many of these “Charters”, which were created at the beginning of the project, some were very voluminous, were even beautiful, with a clear content, a description of the processes, but most of the processes on the project were not executed. And this did not mean that everything was bad on the project! Just the actual processes on the project did not match the formalized in the document. I am not a supporter of this discrepancy, but the projects are in progress and the results on such projects are obtained.
Why it happens?
It is necessary to understand that if the Customer does not have a project management built up, you cannot take it and implement it right away, start to make your project beautifully, in accordance with the project technology. Project management is a separate management approach that differs from the regular one. The implementation of its processes requires considerable time, and often a whole separate large-scale reengineering project. Therefore, there is such a thing as the maturity level of project management in a company. Those. the company (Customer) is ripening gradually, consistently. So simply from one level to the next customer will not jump and do not have to dream. Transitions can last for years.
There are several standards that describe project management maturity models.
The most famous of them are:
See, for example, the table “System of measurement of the level of maturity of management” in Wikipedia, it presents typical levels of maturity and their signs.
We see that only at level 2 "Managed" ("Repeatable") "appears the design approach in its initial form. Therefore, if you want your actions on paper to match your actual actions on the project, assess the maturity level of the Customer’s project management before drawing up the Project Management Plan. My recommendations are as follows:
In principle, there is nothing terrible if you make a full-fledged project management plan that does not work. He, besides the above-described applications (protection and marketing), sows the seeds of project management from the Customer, his employees will know that this is the case, will think, and possibly grow them with time.
And then life began and the processes went their own way, making decisions in their own way, and the document remained on the shelf. Sometimes the RP gets it to show that the Customer does not comply with the deadlines, or violates other agreements. But this is done when the project increases tension and the parties need to defend themselves. There are situations when the RP is trying to update the processes, but often they look at him “askew” as a bureaucrat who, instead of the result, deals with “pieces of paper”.
As a result, such a document fulfills the function of protecting an RPC or Contractor, or a marketing function for the Contractor: “Cool! You are working on project technology! ” And I would like the document to work.
First, let's understand the concepts. In the IT project industry, I often observe how two documents, the Articles of Association and the Project Management Plan are combined into one document, calling it the “Project Articles”. Probably, there is nothing terrible in this, especially when this “Charter” created at the beginning of the project is no longer used in the implementation of the project. But if you need to get working documents, you need to turn to the sources.
')
According to PMBoK: “The project charter is a document issued by the project initiator or sponsor who formally authorizes the existence of the project and gives the project manager the authority to use the organization’s resources in the project’s operations. It documents business needs, assumptions, limitations, understanding customer needs, high-level requirements, and a new product, service, or outcome that you plan to create. "" A project management plan is a document that describes how a project will be executed, how it will be implemented. monitoring and control. It integrates and consolidates all the support and base plans resulting from the planning processes. ”
So, the project charter is more static than the project management plan. He defines the essence of the project itself, it is an order from the Customer (or the Sponsor) to the Project Manager (hereinafter referred to as "RP"): it is necessary to make a project in such a specific framework. If it is necessary to change the fixed in the Charter, then for the RP or the Contractor it is a reason to revise the contractual relationship with the Customer. Accordingly, this document is made by the Customer or Sponsor, and not RP or the Contractor. It is important! We will not focus on the fact that the Project Management Plan is not a schedule, as some perceive it. Here, perhaps, affects the history of the use of the word "plan" in the Russian language. The project management plan talks about how the RP and the project team will execute and control this project to achieve results within the boundaries and parameters described in the Bylaws. This document is more dynamic, it is changeable in the course of the project, since it will not be possible to immediately identify all processes.
A project is a unique enterprise, and accordingly it has a unique set of processes. It is possible to assume at the beginning of the project, to plan some variants of the processes, but the project’s approach will reveal the nuances correcting them and this is normal. As Dwight Eisenhower said: “The plan is nothing, planning is everything. Any plan becomes outdated at the moment when you have completed its development. But in the planning process, you and your subordinates get one look at the situation and decision criteria, therefore, at the time of surprise, they will choose the right decision. ” Therefore, in the PMBoK process diagram, the project management plan is the output of several different processes, which is not the case with the project charter. Thus, the first reason for posting these two documents is their different purpose. The second reason is the dynamics of their changes. If you manage change, you will understand the importance of this reason. There is a third reason. At the time of project initiation, it is impossible to accurately determine how the project will be executed. After the appointment (with the help of the Charter) of the RP, it is necessary to form a team, define contractors, build the organizational structure of the project, decompose the content, think over effective processes. This can sometimes take months. Therefore, the Project Management Plan is born later than the Charter.
After you have understood the concepts, let's talk about why the Project Management Plans, which many people call “Charters”, do not work. I have seen many of these “Charters”, which were created at the beginning of the project, some were very voluminous, were even beautiful, with a clear content, a description of the processes, but most of the processes on the project were not executed. And this did not mean that everything was bad on the project! Just the actual processes on the project did not match the formalized in the document. I am not a supporter of this discrepancy, but the projects are in progress and the results on such projects are obtained.
Why it happens?
It is necessary to understand that if the Customer does not have a project management built up, you cannot take it and implement it right away, start to make your project beautifully, in accordance with the project technology. Project management is a separate management approach that differs from the regular one. The implementation of its processes requires considerable time, and often a whole separate large-scale reengineering project. Therefore, there is such a thing as the maturity level of project management in a company. Those. the company (Customer) is ripening gradually, consistently. So simply from one level to the next customer will not jump and do not have to dream. Transitions can last for years.
There are several standards that describe project management maturity models.
The most famous of them are:
- P3M3 - Portfolio, Program and Project Management Maturity Model - Model of portfolio, program and project management;
- OPM3 - Organizational Project Management Maturity Model - Model of organizational project management maturity.
See, for example, the table “System of measurement of the level of maturity of management” in Wikipedia, it presents typical levels of maturity and their signs.
We see that only at level 2 "Managed" ("Repeatable") "appears the design approach in its initial form. Therefore, if you want your actions on paper to match your actual actions on the project, assess the maturity level of the Customer’s project management before drawing up the Project Management Plan. My recommendations are as follows:
- For level 0 “Missing”. It makes no sense to make a project management plan, no one will implement it. Make a Charter, put in it the main parameters of the project: Sponsor, Customer, RP, goals, objectives, success criteria, the main stages and their results, the composition of the working group. If you are a Contractor, then reflect it directly in the contract or application.
- For level 1 "Initial". In addition to the Charter, you will have the beginnings of a project management plan: you can specify the organizational structure of the project, the rules of document circulation on the project with the timing of the coordination of documents.
- For level 2 "Managed" ("Repeatable"). Most likely, the Customer already has a certain example of a regulatory document that he applied on other projects. It is advisable to understand how it is performed on these other projects. You can visit them and analyze. Immediately remove what is not done and take this document as a basis. But there is no point at this level to describe the processes of risk management, communication management, content management.
- For Level 3 “Defined” (“Standardized”). Most likely, the Customer already has a certain format of the Project Management Plan. It is also desirable to understand how it is performed on the example of other projects. But there is no point in describing risk management processes at this level.
- For Level 4 "Measured" and 5 "Optimized." At this level of maturity, the Customer basically has all the processes for the full management of projects and their risks. The project management plan will be complete. Employees are already working in accordance with the prescribed processes and have developed the necessary skills.
In principle, there is nothing terrible if you make a full-fledged project management plan that does not work. He, besides the above-described applications (protection and marketing), sows the seeds of project management from the Customer, his employees will know that this is the case, will think, and possibly grow them with time.
Source: https://habr.com/ru/post/351528/
All Articles