Joseph Phillips: Writing the Project Charter

The project charter authorizes the project. This document officially initiates the project and gives the project manager the authority to use organizational monies and resources to reach the objectives of the project. It’s a powerful document, and without one of these you’re setting yourself (and often your project) up for failure.

When I consult or teach on project management there’s always some discussion about the project charter and who creates the thing. For some organizations the charter is a boilerplate document. The project manager and customer slap in some details, and it’s considered done. In other organizations the charter is written entirely by the project sponsor. While still other project managers report that they write the charter, and the project sponsor signs the charter as if they wrote the thing.

Here’s what matters when it comes to writing the project charter – it doesn’t really matter who writes the charter as long as the person who signs the charter is the right person. In other words, the person backing up the charter must be the person with the authority to back it up. The person signing the charter should have the authority within the organization to grant the project manager time, money, and resources to reach the project objectives.

So what does the charter define? The project charter has to define all of the following either directly in the charter itself or reference other project documents:

• • Requirements for satisfaction. This is one of the most important details of the project charter. The project manager, the project customers, and the project team need to know what it takes to satisfy the project before they launch into the work. It’s hard to hit a target if you don’t know what the target is.
  • High-level purpose. The charter should define why the project is being initiated and how it fits into the organization’s strategic plans. The charter might accomplish this by referencing the project scope statement, the preliminary project scope statement, or it can fire away and define the business case and business needs the project will satisfy. (I realize I’ve not defined the project scope statement yet – it’s one of the first documents you creating in the planning process group. The project scope statement defines all that’s in the project – and all that’s outside of the project.)
  • Project purpose. The charter needs to specifically identify why the project is being initiated and what the expectations of the project are.
  • Milestone schedule. Milestones are points within the project that show the project is progressing towards completion. For example, in construction, you might consider the completion of obtaining construction permits, the foundation, framing, and landscaping all milestones.
  • Stakeholder influences. A stakeholder is anyone that has a vested interest in the project outcome. Recall that there are positive and negative stakeholders. All stakeholders and their influence over project decisions need to be identified in the project charter.
  • Functional organizations. Projects are rarely isolated events. Projects often interact with lines of business, departments, communities, and government agencies. The project charter must identify all of the functional organizations that the project will interact with and what their contributions to the project may be.
  • Assumptions. Assumptions are things that are held to be true, but they haven’t actually proven to be true. Project assumptions are documented in the project charter to communicate what the organization, project sponsor, project manager, and key stakeholders believe to be true about the project. For example, it is assumed that the software the project is creating will work with the current operating systems the organization uses.
  • Constraints. Boo! Hiss! A constraint is anything that limits the project manager’s options. Constraints always include time, money, and scope. Other constraints can be human resource constraints, materials, equipment, even vendors.
  • Summary budget. The project charter defines what the project’s budget should be. This is often based on the rough order of magnitude estimate which can have some wild swings.
  • Contract. Projects are often completed by one organization for another. The contract defines the terms of the agreement and what the customer and vendor expect from one another as a result of the project. Not every project, of course, has a contract so not every project charter defines a contract.

Real World Note: Let’s reflect on that summary budget for a moment. Here in this big overview of project management it’s easy for me to say blah – you need a summary budget based on X, Y, and Z. I’m not a simpleton; I know that organizations often slap a price tag on a project based on historical information, shallow research, or based on what’s left in the bank account to get a project done. Every organization works differently regarding how projects get funded. The note here is to learn how your project gets funded and then act accordingly.

<

Related posts:

1. Jim Owens PMP: Who Writes the Project Charter?
2. Joseph Phillips: Initiating the Project
3. Joseph Phillips: The Technical Side of Project Management