Introduction

Lola was excited to begin her project to create a donors’ database. Now that she had defined the why and what of the project, created a project plan, and understood the relationship among budget, schedule, and scope, she was well on her way to delivering a successful project. Lola was surprised that all of this planning took up so much time before she could actually start working on the project. She was even more surprised when I told her during our third visit to the coffee shop that she was not quite done!

My final pearl of wisdom respecting the planning phase of a project is to write a Project Charter. It is the document that will bring all of the above information together, and which will be used to help govern the project. When I described what was in it, Lola noted that it is very similar to a Terms of Reference. She was right. The Project Charter serves as the Terms of Reference for the project.

Why Write a Project Charter?

Lola was more interested in initiating her project and beginning to get some “real work” done. She had spent so much time planning and was getting pressure to begin producing some results. I too have often been in that situation. The project sponsor or stakeholders want to see some hard results, and are not interested in the project team taking the time to create a Charter. Projects are similar to building a house though. You need a solid foundation before you can put up walls.

The Project Charter will benefit the project by:

• Ensuring that everyone understands why the project has been initiated and what it will produce (i.e. Project Overview Statement).
• Identifying and communicating what needs to be done to complete the project (i.e. Project Plan).
• Communicating to all project team members what they are responsible for delivering in the project (i.e. Roles and Responsibilities Chart).
• Articulating the “rules” of the project so that everyone knows how the project will be governed (i.e, Project Management Plan).

Contents of the Project Charter

The Project Charter has a fairly consistent format whether the project is a small one, such as developing a donors’ database, or a very large one, such as building a new space shuttle. The only real difference is the amount of detail found therein. For most projects, a brief Project Charter of five to ten pages is probably more than enough. It should contain the following information:

1. The “why” and “what” of the project

• This should be the easy part. You have already created the Project Overview Statement. Simply paste this information into the beginning of the document and you are done!

2. Roles and Responsibilities Chart

• List the key people working on the project and write down what they do on the project. This might be an activity such as “Provide expert advice on database design” or a deliverable such as “Training manual”.
• For Lola’s project, the key team would consist of her, the executive director, the two programmers, and the person writing the training manual. There might be others who attend the occasional meeting or do a little bit of work on the project, but they would not be considered core members of the team.

3. Deliverables and Milestones Chart

• List all of the key deliverables and milestones and the expected date of completion. What are the most important things that have to be created to get the project done? What milestones will indicate the project is moving forward? There should not be more than ten or fifteen, and they will be taken directly from the Project Plan (which you might want to attach as an appendix).
• Lola defined her key deliverables as a donors’ database, a training manual, and a training session for the users. That is a great start, and she could include a few more. For example, the Table of Contents for the training manual might be considered a key deliverable. The above information adequately defines the project, but there remains the Project Management Plan that needs to go in the second part of the Project Charter. Although there are many parts to the plan, I want to highlight only two that are critical to project success.

4. Communications Strategy

• One of Lola’s strengths is that she is an excellent communicator. She understands that projects consist of people, and people need to communicate. The project team must communicate with one another, with the project sponsor, and with other stakeholders.
• List all of the people or groups of people with whom your project team must communicate. Write a description of your communication with them. It should include: how often (e.g. weekly, at project end); in what format (e.g. meeting, report, email update); what they need to know (e.g. status update, project overview, budget information); and who will be responsible for providing it.

5. Change Management Strategy

• Projects change. It cannot be helped. Funding is cut. The schedule gets delayed. The project team needs to redo a piece of work. The goal of project management is not so much to prevent change, but to understand its impact and make changes to the budget, schedule, or scope as required.
• Include a description of the process for addressing change. Who will investigate the impact of a change? Who will approve the change? How will the change be documented?

Summary

A Project Charter sets the foundation for delivering a successful project because it defines what the project is all about and how it will be governed. Lola found that the project definition was relatively simple because she already had the Project Overview Statement, the Project Plan, and identified the project team. She was concerned about writing the Project Management Plan. My response to her, and to you, is to do the best she can. It is an important exercise, if only to keep in mind that she needs to communicate and needs to address changes as they arise in the project.

Now that you have created the Project Plan, the fun begins! It is time to begin managing your project. In future articles, we will discuss the issues of daily project management, and provide you with tips on managing cost, schedule, risk, and all that other fun stuff!

Blair Witzel (blair@mcdoane.com) is a member of the Project Management Institute and a consultant with McDonnell Doane + Associates, an information management and technology firm focusing on the not-for-profit and public sectors. His work centres on managing multi-project portfolios and working with organizations to develop project management methodologies to more effectively deliver projects.