How to Write a Project Charter?

When learning how to write a Project charter it is important that you bear in mind the reason why you are writing one. The end goal is ensure that you, the Project Manager are given the authority to deliver the project and use resources to do so. Further it is to lay out the end result which the project will deliver.

Just because a Project Charter is a significantly cut down version of a Project Initiation document (PID), does not mean you can skimp corners without it causing problems later on.

The high level key elements which are usually included in the Project Charter include:

• 1.0 An Overview of the Project
• 2.0 Justification for the Project
• 3.0 Proposed goals for the Project (scope)
• 4.0 Proposed Deliverables
• 5.0 Proposed Roles, Responsibilities and Authority
• 6.0 Approval

1.0 An Overview of the Project

This is usually includes the purpose of the project including the background behind it and the proposed scope. Sometimes it can also contain a very high level milestone plan.

2.0 Justification for the Project

This contains information detailing why this project needs to be done. So for example if the project is to upgrade the server hardware, the company website is hosted on, then you would state that the project needs to be done because otherwise the performance of the website will be unduly impacted leading to a reduced user experience which could adversely affect the Organisation's reputation.

3.0 Proposed Goals for the Project - Scope

As in writing a Project Initiation Document it is worthwhile spending time on ensuring you get an accurate Project Scope Statement written which leaves no room for assumptions to be made. Confusion over project scope are one of the major causes of scope creep.

4.0 Proposed Deliverables

This is a list of the deliverables which the project will deliver on completion. It needs to be written clearly so that team members are completely aware of what they are responsible for delivering. You also need to specify what format the deliverable will be in. So for example is a Word document expected? Is it a Visio flow chart?

5.0 Proposed Roles, Responsibilities and Authority

This section importantly designates you as the Project Manager in charge of this project, whilst summarising your authority. For example this would include the level of decision making the Project Manager would be able to make as well as financial sign off. In practice this would mean something along the lines of,

"The Project Manager is empowered to make decisions on scope which do not impact timeframes, project budget or project management resource allocation as long as these are then ratified at the Project Board. They are also allowed to make project purchases up to the amount of $1,000 without further project sponsor approval. Anything over this amount will need further authorisation".

Another key part of this section involves defining what everyone on the Project is doing. Now you may assume that team resources will use some common sense and work out what their role and responsibilities on the project are, but you would be amazed how many seem completely clueless without a team chart!

So write down a list of project management stakeholders, what their responsibilities are and how issues are escalated through them. Do a similar exercise for the team members but try to also document it in an project organisation diagram as shown in Writing a Project Initiation Document - Governance.

6.0 Approval

Unlike a PID, a Project Charter can usually be approved solely by the Project Sponsor, with perhaps a quick tick in a box from Finance.

Now that you've completed and got approved your Project Charter it's time to get your project started and get on with the hard work of delivering it!

How to Write a Project Charter? - Tip

Don't skimp on writing either the Scope, Deliverables or Roles and Responsibilities section. Whilst a Project Charter is a quick way of getting a project started, the same problems tend to impact all projects, whether small or large. And this often involves confusion over scope, deliverables or roles. So spend the time getting these accurately documented, and you could be saving yourself a large number of headaches later on in the project management lifecycle.