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.
1. Table of Contents
The table of contents in my Project Charter Template is as follows.
- Project objectives and scope
- Project benefits
- Approach, dependencies and critical success factors
- Project governance
- Roles and responsibilities
- Key contacts
- Project milestones
- Project risk factors
Let’s run through each of these sections in turn.
2. Details Of Each Section
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.
Project objectives and scope
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.
Approach, dependencies and critical success factors
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:
- What steps need to be taken to deliver the project?
- What deliverables are produced at the end of the project and at each milestone?
- What are the key dates in the project timeline and the significant milestones?
- When will each deliverable be completed and signed off?
- What dependencies (on other projects or business initiatives) does this project have?
- How does the project team know when success is achieved? What does success look like? What are the critical success factors (very common question in all projects)?
Tip: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:
- Maintain regular communication between the client and ABC (my company)
- Clear roles and responsibilities
- Agreement of project milestones and commitment from both the client and ABC to achieve the agreed timeframes
- Compliance with all applicable laws, including statutes and regulations
- Timely delivery of accurate data, information and supporting documentation by the client
- Timely responses to requests from both the client and ABC
- Coordinated approach to minimize disruption to the client’s day-to-day business operations
- Minimal functionality to be rolled out in the initial phase
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
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.
Project risk factors
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:
- Issues or events that occur during the project that result in a need to amend the scope or objectives.
- Another project on which your project is dependent gets delayed
- Project issues arise and cannot be resolved at the ground level
- A change of project sponsor occurs
- … and there usually are a LOT more – anything that has a negative impact on your budget, schedule, resources or quality of work is also deemed a project risk factor.
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.
Wrapping Up …
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!