You know, one of the most important documents in a project is the Project Charter. It is usually developed in the “Initiate” process group in the PM Body of Knowledge.
Here's a recap of what a project charter is.
A project charter is a “high-level project map”, a statement of a project's objectives, scope, stakeholders and their roles and responsibilities.
To help you with defining your own Project Charter, I want to share with you a template that I use very often in my projects. Of course, you will need to customize it to suit your needs, but 80% of what's in there should be re-usable.
You may download a copy of my Project Charter Template here.
The table of contents in my Project Charter Template is as follows.
Let's run through each of these sections in turn.
In this section, you insert an introductory paragraph outlining the nature of the client's business and the purpose of undertaking the project. This is essentially an overview of what the rest of the document contains, summarized in a few short paragraphs.
What is the project trying to achieve? What scope does it cover? Does it cover one country or multiple countries? What functionalities or departments are involved? Which are not involved? You should spell this out clearly within this section.
An important but often ignored section. If a project is worth doing, its benefits must be tracked or reported somehow. In this section, the project manager should define the benefits and related assumptions associated with the project. These may be quantitative or qualitative in nature. Also, tracking and reporting of realized benefits is also described in this section, if applicable.
It's very important to reflect in the Project Charter how you're going to deliver the project. The key areas you have to address are:
One thing I quickly learnt as a project manager is that you MUST know when project success is achieved. It cannot be fuzzy or grey. Project success must be explicit and well communicated to all stakeholders.
I can tell you, it's amazing how many project teams don't understand “what success looks like” when they embark on a project. And they end up changing requirements, having the wrong expectations, doing all the things that bring about project failure.
The usual methods of “quantifying project success” (as I call it) is to use “deliverables” and “delivery dates”. What are the physical documents or artefacts that will be produced at the end of the project? When will each of them be delivered?
Some more astute project managers will even create detailed section-by-section “checklists” for each deliverable. Once a user accepts and is ok with a section, it is ticked. This makes the delivery very concrete and explicit, as opposed to being fuzzy or fuddy-duddy.
Another point to highlight is that of “critical success factors”. Here are some examples:
Think of these critical success factors as guiding principles which should be printed out and taped to the wall of every project team member and stakeholder.
Some project charters don't have this - but I think it's important. Protocols are something like a service level agreement. For example, if there is a project issue that the ground level cannot agree on, it needs to be tabled for resolution at the next weekly project meeting. If the weekly project meeting cannot agree on a resolution, then it is escalated to the monthly Project Steering Committee meeting. Instituting these protocols ensure that there is a structured process and zero ambiguity in addressing any project concern.
Another key section is project governance. You need a diagrammatic view of the project governance structure. Specify where the lines of communication are, who is in the working level group and who is in the Steering Committee.
Roles and responsibilities are closely related to project governance. Here you will specify each role, e.g. “ABC Project Manager”, “ABC Business Analyst” and list out the high level responsibilities and tasks that the role must fulfill. This is very important for clarity and also helps to carve out scope properly.
Case Study: I was the project manager for rolling out a core banking system for a private bank in Malaysia. Because we did not have clear roles and responsibilities mapped out between my company (ABC), the client and the system vendor, ownership of duties was a total disaster. Sometimes the bank would do things for the system vendor and sometime we (ABC) would do things for the client that were out of scope.
You know, just doing up ONE simple slide clarifying roles and responsibilities can significantly increase the chances of project success. I do this for most of my projects and my clients tell me it is a great tool for clarifying expectations. You may want to try it out.
It's useful to also list out the main personnel in the project, the role they're playing, plus their contact details. When there is a crisis and you urgently need to contact your lead business analyst, test manager or a user, you can rest easy knowing that the contact details are within easy reach.
For the benefit of the reader, it's good to list out in a table the key project milestones, their planned start date and completion date, as well as status. One glance at the milestone table and you can tell whether you are on track for delivering the project.
Some people tell me they don't know what to write as “project risk factors”. Well, all I can say is that this section could not be more important!
I'll give you some examples of risk factors:
What's even more important than identifying the project risk factors is to list down the steps to take to mitigate the risk. If a project issue cannot be resolved, what are the escalation steps the project team needs to take? Always take the time to write down the mitigation steps.
And that's it! A quick overview of the Project Charter template I use. Honestly, there are more complex project charters out there, but I like to use this one as it is clean, succinct and addresses most of the issues you'll encounter in a project. There are alternative project charter templates that you may also want to check out here. Until next time, good luck in your project management endeavors!
Are you wondering how to break into a Project Management?
Would you like to understand how others have successfully switched to a PM career?
Or discover what skills, certifications and domain / industry knowledge are required to excel in a PM role?
I’ve written a practical, easy-to-read guidebook that will help you find your best path to Project Management – one that leverages your unique skills, experiences and career background to your advantage.