March 19, 2018 at 19:02Why don't the charters 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 the problems and make decisions, these are the terms we will have for approval , such frequency will be status meetings, etc. And we bring it to him in the form of a voluminous document that way pages 30-50 regulatory text. The customer looks at it with “wide eyes” and says: “Cool!”. That which does not correspond to the practice adopted by the Customer, he will propose to correct, but otherwise the document will be accepted.
And then life began and the processes went their own way, making decisions their own way, but the document remained on the shelf. Sometimes RP takes it out to show that the Customer does not comply with the established deadlines, or violates other agreements. But this is done when tension increases on the project and the parties need to defend themselves. There are situations when the RP tries to update the processes, but often they look at it “askew” as a bureaucrat who deals with “pieces of paper” instead of the result.
As a result, such a document performs the function of protecting the RP-nickname or the Contractor, or the marketing function for the Contractor: “Cool! You are working on project technology! ” I would like the document to work.
First of all, let's deal with concepts. In the IT project industry, I often observe how the two documents, the Charter and the Project Management Plan, are combined into one document, calling it “Project Charter”. There is probably nothing wrong with 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, then you need to turn to the sources.
According to PMBoK: “The project charter is a document issued by the initiator or sponsor of the project, which 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 of customer needs, high-level requirements, as well as a new product, service or result that is planned to be created. ” “A project management plan is a document describing how a project will be implemented, how it will be monitored and controlled. It integrates and consolidates all supporting and basic plans resulting from planning processes. ”
So, the Charter of the project is more static than the Project Management Plan. It defines the essence of the project itself, it is an order from the Customer (or Sponsor) to the Project Manager (hereinafter “RP”): it is necessary to make the project within such certain limits. If it is necessary to change what is fixed in the Charter, then for the Republic of Poland or the Contractor this is an occasion to review contractual relations with the Customer. Accordingly, this document is made by the Customer or Sponsor, and not by the 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, probably, the history of the use of the word “plan” in Russian is telling. The project management plan talks about how the RP and the project team will execute and control this project in order to achieve results within the boundaries and parameters, described in the Charter. This document is more dynamic, it is volatile during the course of the project, since it will not be possible to immediately determine all the processes.
A project is a unique enterprise, and accordingly it has a unique set of processes. You can assume at the beginning of the project that you plan some process variants, but the project’s campaign will reveal the nuances that correct them and this is normal. As Dwight Eisenhower said: “A plan is nothing, planning is everything. Any plan becomes obsolete the moment you have completed its development. But in the planning process, you and your subordinates gain one look at the situation and the 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 does not happen with the Project Charter. Thus, the first reason for the separation of 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 initiation of the project, it is impossible to determine exactly 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, determine the contractors, build the organizational structure of the project, decompose the content, and think through effective processes. This can sometimes take months. Therefore, the Project Management Plan is born later than the Charter.
After we’ve figured out the concepts, let’s talk about why the Project Management Plans, which many call the “Bylaws”, do not work. I saw a lot of such “Charters” that were created at the beginning of the project, some were very voluminous, they were even beautiful, with a clear content, description of the processes, but most of the processes on the project were never carried out. And this did not mean that everything was bad on the project! Just the actual processes on the project did not correspond to the formalized ones in the document. I am not a supporter of this discrepancy, but projects are ongoing and the results on such projects are being obtained.
Why it happens?
It must be understood that if the Customer does not have project management, you cannot immediately implement it and begin to make your project beautifully, in accordance with the design technology. Project management is a separate management approach that differs from regular. 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 level of maturity of project management in a company. Those. the company (Customer) matures in stages, sequentially. So just 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:
For example, look at the table “Management maturity level measurement system” on Wikipedia, where typical maturity levels and their attributes are presented.
We see that only at level 2 “Managed” (“Repeatable”) does the project approach appear in its initial form. Therefore, if you want your actions on paper to correspond to your actual actions on the project, evaluate 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 to worry about if you make a full-fledged Project Management Plan that does not work. In addition to the applications described above (protection and marketing), he will sow the seeds of project management at the Customer, his employees will know that this happens, think about it, and possibly grow them over time.
And then life began and the processes went their own way, making decisions their own way, but the document remained on the shelf. Sometimes RP takes it out to show that the Customer does not comply with the established deadlines, or violates other agreements. But this is done when tension increases on the project and the parties need to defend themselves. There are situations when the RP tries to update the processes, but often they look at it “askew” as a bureaucrat who deals with “pieces of paper” instead of the result.
As a result, such a document performs the function of protecting the RP-nickname or the Contractor, or the marketing function for the Contractor: “Cool! You are working on project technology! ” I would like the document to work.
First of all, let's deal with concepts. In the IT project industry, I often observe how the two documents, the Charter and the Project Management Plan, are combined into one document, calling it “Project Charter”. There is probably nothing wrong with 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, then you need to turn to the sources.
According to PMBoK: “The project charter is a document issued by the initiator or sponsor of the project, which 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 of customer needs, high-level requirements, as well as a new product, service or result that is planned to be created. ” “A project management plan is a document describing how a project will be implemented, how it will be monitored and controlled. It integrates and consolidates all supporting and basic plans resulting from planning processes. ”
So, the Charter of the project is more static than the Project Management Plan. It defines the essence of the project itself, it is an order from the Customer (or Sponsor) to the Project Manager (hereinafter “RP”): it is necessary to make the project within such certain limits. If it is necessary to change what is fixed in the Charter, then for the Republic of Poland or the Contractor this is an occasion to review contractual relations with the Customer. Accordingly, this document is made by the Customer or Sponsor, and not by the 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, probably, the history of the use of the word “plan” in Russian is telling. The project management plan talks about how the RP and the project team will execute and control this project in order to achieve results within the boundaries and parameters, described in the Charter. This document is more dynamic, it is volatile during the course of the project, since it will not be possible to immediately determine all the processes.
A project is a unique enterprise, and accordingly it has a unique set of processes. You can assume at the beginning of the project that you plan some process variants, but the project’s campaign will reveal the nuances that correct them and this is normal. As Dwight Eisenhower said: “A plan is nothing, planning is everything. Any plan becomes obsolete the moment you have completed its development. But in the planning process, you and your subordinates gain one look at the situation and the 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 does not happen with the Project Charter. Thus, the first reason for the separation of 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 initiation of the project, it is impossible to determine exactly 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, determine the contractors, build the organizational structure of the project, decompose the content, and think through effective processes. This can sometimes take months. Therefore, the Project Management Plan is born later than the Charter.
After we’ve figured out the concepts, let’s talk about why the Project Management Plans, which many call the “Bylaws”, do not work. I saw a lot of such “Charters” that were created at the beginning of the project, some were very voluminous, they were even beautiful, with a clear content, description of the processes, but most of the processes on the project were never carried out. And this did not mean that everything was bad on the project! Just the actual processes on the project did not correspond to the formalized ones in the document. I am not a supporter of this discrepancy, but projects are ongoing and the results on such projects are being obtained.
Why it happens?
It must be understood that if the Customer does not have project management, you cannot immediately implement it and begin to make your project beautifully, in accordance with the design technology. Project management is a separate management approach that differs from regular. 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 level of maturity of project management in a company. Those. the company (Customer) matures in stages, sequentially. So just 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 - Maturity model for portfolio, program and project management;
- OPM3 - Organizational Project Management Maturity Model - Maturity model of organizational project management.
For example, look at the table “Management maturity level measurement system” on Wikipedia, where typical maturity levels and their attributes are presented.
We see that only at level 2 “Managed” (“Repeatable”) does the project approach appear in its initial form. Therefore, if you want your actions on paper to correspond to your actual actions on the project, evaluate 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; nobody will implement it. Make a Charter, put in it the main parameters of the project: Sponsor, Customer, RP, goals, objectives, success criteria, main stages and their results, the composition of the working group. If you are a Contractor, then reflect this directly in the contract or application.
- For level 1 "Beginner". In addition to the Charter, you will have the beginnings of a project management plan: you can prescribe the organizational structure of the project, the rules for document circulation on the project with the timing of approval 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 being implemented on these other projects. You can visit them and analyze. Remove immediately what is not running and take this document as a basis. But there is definitely 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 advisable to understand how it is being executed on the example of other projects. But there is definitely no point in describing risk management processes at this level.
- For Level 4 “Measurable” and 5 “Optimizable”. At this maturity level, the Customer, in principle, 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 acquired the necessary skills.
In principle, there is nothing to worry about if you make a full-fledged Project Management Plan that does not work. In addition to the applications described above (protection and marketing), he will sow the seeds of project management at the Customer, his employees will know that this happens, think about it, and possibly grow them over time.