Given that project charters are such important documents, here are some tips for writing better project charters, which will result in better project performance:
Clear Project Goals
"Management by objective works - if you know the objectives. Ninety percent of the time you don't." Peter Drucker
Charters typically start with the project name, but far more important is the project goal. What exactly is the project setting out to achieve, and what does success look like? Be crisp about this; the goal should be less than a paragraph, ideally a sentence, and ideally refer to key performance indicators later in the document. For example, "Upgrade our IT systems" is not a clear goal.
- Who are the systems being upgraded for?
- To what version?
- When will this be finished
- For how many users?
- Is it merely upgrading, or does scope extend to training and usage?
- Will the system be customized, based on user feedback or deployed without modification?
- Will the project include any ongoing support?
A clearer goal is "Enable the 135 employees within PPMCo's accounting and financial departments to perform SEC compliant project based accounting for the 2011 fiscal year, and train the 135 employees so they are able to maintain and support the new process themselves."
Firstly, the goal doesn't have absolutely all the answers, but it sets things up well for detail later in the document. You'll also notice that the example goal above does not include the IT system itself, that's intentional, just deploying the IT system will not meet the goal, the goal is to improve accounting within the organization, not simply to roll out a new piece of software. It has been determined that the IT system is the way to reach the goal, but not the goal itself. This is a critical distinction, and the project charter should make this distinction.
The Dialogue is as Important as the Charter that Results
A significant part of the value of a project charter results from the dialogue that should surround its creation. Ideally, the project charter is the summary of a round of critical discussions. Since the project has not begun when the charter is written, it gives a great opportunity to discuss potential trade-offs before the project starts. This is typically a much better time to have the discussion because the pressure is much reduced when there is no angry client, sub-contractor or supplier phoning, emailing or knocking on your door. By having these discussions in advance they are much easier and a number of problems can be avoided before they even occur.
For example, is it more important to finish a week earlier or save $20,000? Is user satisfaction more important than consistency with other systems within the organization? Is the director of finance to be held accountable or consulted for a particular task? Bear in mind that this is the document the project sponsor puts their signature on, so it carries a lot of weight and can be used to lay out the framework or decision structure for as many decisions as possible in advance.
This may feel like overkill and an unnecessary burden, but remember that the project manager will have much less time once the project is in flight, and the project sponsor might be on vacation or in a different time zone as key uncertainties arise. Taking time to be thorough in production of this document will pre-empt as many potential issues as possible. It will save a great deal of time once the project is in progress, because rather than kicking off a series of meetings to solve a problem, onc can simply refer to the project charter for many answers about scope, roles, trade-offs and so on. The project charter will also empower decision making by the project manager, because the needs of the project sponsor are set out in the document.
"Be candid with everyone." Jack Welch
Any project charter should define roles, but there is an opportunity to be clear on what those roles really mean, rather than just citing job titles. There are many frameworks for doing this. I recommend using a PACE framework to define roles. PACE stands for the roles within the framework (Process driver, Accountable, Consulted, Execution):
Process Driver: The responsible party does or assigns the work for a particular task and makes decisions after consulting with the accountable party. The process driver has a close relationship with the accountable party, who can veto their decisions. The process driver assigns work to those in execution roles and engages with those in consulting roles.
Accountable: The accountable party signs off upon completion of the task. The accountable party will work closely with the process driver and is more powerful than the process driver in that they can veto their decisions.
Consulted: Participates in two way communication. This group participates in decisions related to the project, the process driver makes the decision, and they should not escalate problems to the accountable party. Note that being consulted does not necessarily mean you get to make the decision, but you do have the opportunity to have a dialogue with the process driver and influence the process.
Execution: Receives one way communication and may work on particular sub-tasks An informed party gets to receive communication about what is happening. The nature and frequency of the communication should be outlined. However, the informed parties do not have the right to force any kind of decision regarding the project. For project success, moving as many parties from the consulted to informed group as possible will help speed communications.
The PACE model can either apply to the entire project if tasks are consistent, but more often the PACE roles differ depending on the tasks in question. Of course, usage of the PACE model does entail some difficult discussions up front, but it is far better to have those discussions once before the project starts than to manage ongoing ambiguity in relationships and roles as the project progresses.
Identify a Mitigation Strategy for Each Risk
"Risk comes from not knowing what you're doing." Warren Buffett
Risk management should happen at every stage of the project, including the project charter. Whenever a risk is identified, a mitigation strategy should also be identified and this should happen as early as during the project charter. Merely identifying risks without any thought for mitigation, should it occur, has limited value. Once again, this is a valuable opportunity to empower the project manager to solve risks, rather than going back to the project sponsor, and it means risks can be resolved quicker. Of course, there is still the possibility that unexpected risks arise, but investing time in mitigating other risks will enable the project manager to better identify material, unexpected risks as they arise.
Share the Project Charter Broadly
Just as the project charter is a good opportunity to have a detailed dialogue with the project sponsor and others, it is also an opportunity to reinforce transparency within the organization and build awareness of the project that is about to launch. Rather than just pulling out the charter when a dispute arises, the project charter should be broadly shared at the inception of a project to inform people of the project's existence. This will also save some time for the project manager, as the project charter should answer a number of questions that people might have about goals, roles and scope which they would otherwise ask of the project manager directly. Writing a great project charter entails significant time and effort on your part, so ensure that you get the full benefit by sharing the charter broadly.Don't forget to leave your comments below
Simon Moore is the author of Strategic Project Portfolio Management (Wiley, 2009) and the Strategic PPM blog. He holds an MBA, CFA and an undergraduate degree from Oxford University. He is a product planner for Microsoft determining international requirements for future Microsoft Business Division products including project management tools.