Writing a project charter

Everyone knows that the charter of the project is the beginning of all project work. It is with him that the start of the project begins and it is he who formally announces the existence of the project in the company. However, often project managers make one mistake when writing a charter. 

 

They pay too much attention to it, trying to squeeze into the document what it is not intended for. Let's consider an example of such a situation.


In one small company, let's call it traditionally, "Horns and Hooves" decided to keep management records of the centers of financial responsibility (CFD). 

 

Although the financial director was engaged in such accounting at the previous place of work, the establishment of management accounting for the Central Federal District at the enterprise was an uncharted area for him. 

 

In the company, in the information technology department, a project manager worked, not very experienced, but not to say that at all without experience. And they decided to initiate the project.



It was convenient for the financial director that the project manager would take over the entire organizational part of the work, and the project manager was interested in the idea, although not new. Said and done. We held a meeting, identified stakeholders, risks and even determined the scope of work on the project and the stages into which it will be detailed.



There were not so few stakeholders, as many as seven: the CEO, who reported to shareholders and was responsible for the work of the company, the financial director, who was responsible for preparing management reports and controlling the costs of the units, a young specialist in the financial planning and control department, performing reporting work, the chief accountant providing data for reporting, the head of the selling division and the director of the department information technologies, the work of which was to be affected by innovations.


Having decided on everything that should have been included in the Charter, the head of the newly minted project sat down to write it. There were only nine sections in the charter: the rationale for the project, the goals and objectives of the project, the appointment of the project manager and his authority, project stakeholders and their requirements, project roles, project structure, initial project risks, project approvals, measurable project goals.


After suffering for a couple of days and writing the Charter, the project manager sent it electronically for coordination with all interested parties of the project. A couple of days later, the first edits from the chief accountant arrived. A week later, all the edits were collected, but as it turned out, many of them contradicted each other, because the interests of many interested parties were different. The project manager was faced with a choice: to escalate the problem to the CEO or try to convene a meeting and come to a consensus.


Choosing the second path and writing the agenda of the meeting, the project manager sent out invitations to the meeting to all interested parties. However, as it turned out, the head of sales on the day of the meeting flew on a business trip and the meeting had to be postponed for three days. After the last meeting, having fixed the agreements in the protocol, the project manager redid the charter and sent it again for approval. But I got repeated edits.



After doing a couple more iterations with meetings and edits, the project manager still came to a logical conclusion, in order to exclude disputes and contradictions, it is necessary to exclude controversial points. By removing the controversial items from the Project Charter, the project manager quickly managed to agree on it. The project has officially started.



I think the gist of the problem is clear. The project charter is a document that is not intended for fixing the scope of the project, or a detailed description of the requirements. This document is intended only to indicate the formal start of the project, the appointment of a project manager, the definition of high-level project objectives and, in general terms, the risks of the project. It should not contain details.



It must be remembered that each document must appear in a timely manner. At the initial stage, the project manager dives into the essence of the project much deeper than other interested parties, but this does not mean that all the knowledge gained must be coordinated in writing, with all interested parties. Later, when other participants get involved in the project, it will be much easier to agree on documents containing important information.