Project Charters 101
Charting a Course to Success
“First, have a definite, clear practical ideal; a goal, an objective. Second, have the necessary means to achieve your ends; wisdom, money, materials, and methods. Third, adjust all your means to that end.” —Aristotle
A Project Charter is perhaps the single most important document you must create on your project. Before you begin anything else on the project. And no, this is not hyperbole. Without a Charter (or its functional equivalent), you, as the project manager, can’t actually be certain what you’re supposed to be doing on the project. Or what you’re tasked with creating and delivering. Or even whether you’re allowed to do anything or not!
Without a Charter, you don’t know what project success is supposed to look like, what is and isn’t included in the project, who the key people involved in the project are, how much this thing is supposed to cost, when it’s supposed to be finished… and so on. In fact, without a Project Charter, you don’t have any real authority to manage your project.
Sounds important? Oh yeah, it really is. Let’s take a closer look….
What Exactly is a Project Charter?
A project charter is the highest level document within a project. In a sense, a Project Charter serves as the “birth certificate” of your project, authorizing, legitimizing, and defining the project. This is a 30,000ft-level view of your project. It’s the initiating document that authorizes the very existence of the project and sets out the important key high-level targets, goals, and/or requirements. Essentially all documents, requirements, plans, specifications, and other key information on your project spring from (or must ultimately be traced back to) the Project Charter.
The term Project Charter derives from the word “Chart”, which implies a map or guiding document. And that is exactly what it’s intended to do on a project—serve as a combination of roadmap and navigation beacon. Without a Project Charter (or something very similar), you literally can’t be certain what your project is tasked with creating. As some wag once opined, “if it ain’t written down, it ain’t real.” In other words, your Project Charter is the big picture, “written down” definition—and authorization—of your project.
Project Charters can be simple or complex. They can range from basic 1-2 page documents, to dozens or hundreds of pages of complex and detailed information. I tend to prefer simple over complex, even on big projects, but every project and situation is different, so what is applicable to one may not at all be applicable to the next….
…ah, but that said, every Project Charter should include some of the same basic key information. We can arrange these into six major categories:
Mission Statement. Right at the top of every good Project Charter is an executive summary of what the project is fundamentally about. It can/should be at most a paragraph or few long, and it can/should summarize the highest level information about the project. It includes a high-level description of the expected deliverable from the project, along with a high-level explanation and/or description of why this project is needed (i.e., the “business case.”) Sometimes, this business case is specified in a separate standalone document (which is then referenced from the Charter).
The Project “What’s”. The first major section of a Project Charter should address and answer the big picture “What’s” of the Project. At its heart, this is a high-level view of the “Golden Triangle” of your project. This section of the Project Charter must answer these four basic things:
Scope. What—specifically—are you tasked with producing and delivering? And, just as importantly, what isn’t included in this scope? This is a high-level view of the project; in no way is every individual piece of delivered scope defined in this document (or even necessarily known at this point), but the big building blocks absolutely are defined. Every project delivers something(s), whether it’s a product, service or result. You can’t fully start a project unless and until the broad strokes of this are determined and spelled out clearly to you and your stakeholders in writing. Said simply, this is the high-level definition of what the customer wants you to deliver.
Quality. What—specifically—are the high-level quality requirements placed on the aforementioned deliverable (scope)? I.e., from a big-picture point of view, just how “good” does the delivered Scope have to be in its finished state? What level of quality is required? What does “good enough” look like? This can and should include high-level form, fit, function, performance, reliability, ES&H, and lifetime requirements. Again, we don’t need (or want) every little specification spelled out here; instead, it’s just the high-level requirements and specifications that the customer ultimately wants the deliverable to be able to do.
Schedule. What—specifically—are the big-picture time constraints placed on the delivery of the scope? How much time is allocated to completing the project? Do you have a week, a year, or a decade to deliver the deliverable? Is there a hard deadline that must be met? Or is determining the big picture schedule part of your deliverable? And are there any high-level key milestones that have to be met along the way, and, if so, what specifically are they? Again, what does the customer want and need from a schedule point of view?
Budget. What—specifically—is the overall budget that you have to work within? How much is this project expected to cost? Is this an estimate that needs refinement, a ballpark allowance, or a hard-fixed figure that you have to adhere to? Is contingency included, and if so, how much? What about management reservers? And where, how, and when is this money going to be provided (i.e., funding profile)? Oh, and are there any other resources, assets, supplies, equipment, personnel, or other specific things that are going to be allocated to you by management to perform the work?
The Project “How’s”. Just as important as the “What’s” of a project are the “How’s”. Specifically, how are you going to perform and deliver the deliverable? There are three major sub-categories of hows:
Procurements. How is it envisioned that the project will produce the scope? This includes activities such as design, analyze, review, procure & fabricate, assemble, test, verify, ship, and deliver/verify that the scope is created within the quality requirements. Will this work be performed all or in part in-house, via external contracts, with R&D development, or something else? You don’t have to lay out all the answers here, but you do need to set out and define high-level expectations.
Work Execution/Integration/Communications. How will the work be executed, monitored, tracked, controlled, course-corrected, and, ultimately, reported on? This also includes the high-level communication plans and procedures/policies/methodologies of the project. Sometimes, this is called the PEP, or Project Execution Plan of a project.
Risk Management. The third “How” is related to threats to your project. How will risks be managed? Every project has internal and external concerns that threaten its successful completion. You don’t necessarily need to define what those specific threats are here (unless they are fundamental to defining the project), but you do have to describe how risks will be identified, tracked, and managed.
The Project “Who’s”. At the heart of every project are the people doing the work and those that care about the work. We call these the “Who’s” of a project. The Project Charter should define these entities:
Key Project Personnel. Again, you don’t necessarily lay out the entirety of the proposed project org chart here, but you do need to define the key roles and responsibilities, as well as an approximation of the size and make-up of the project team. Give names to any and all specific people who will be taking on vital positions, such as a specific subject matter expert (SME), who is critical to the success of the project, plus specific areas like safety management or systems engineering. Oh, and this includes you, the Project Manager, along with a declarative statement that you not only are taking on the responsibilities of the position, but also that you are given actual authorities, such as the ability to hire/fire personnel, spend money, authorize changes, and direct the entire course of work.
Key Stakeholders. Every project will have a variety of stakeholders, both minor and major, who have interest in and influence over your project. The Charter should identify the most important and relevant of these stakeholders, along with their basic desires, roles, responsibilities, and levels of authority upon the project. For example, if you have an external funding agency, you need to clearly state the who’s, what’s, when’s, and how’s of their involvement.
Other Key Information & Requirements. Every project is, by definition, unique. This section of your Project Charter may contain dozens of additional high-level aspects, requirements, and data, such as expected partnerships with other groups and institutions, operational handover requirements not covered in the Quality definition, special close-out or end of project requirements, and so on. In other words, any and all of the important, high-level unique requirements, conditions, and/or information, not covered elsewhere in the Project Charter, that is needed for you to define the project and manage the high-level expectations of you, your team, your corporate overseers, and your key stakeholders.
Appendices & Links. This last section of a Project Charter references and/or links to key supporting documents necessary to more deeply understand the Charter. This might include things like detailed concept and trade studies performed to date, scope analyses, technical studies, specific supporting information for the business case, cost studies, R&D reports, and so on. Again, every project is unique, so this section—if it exists—will be unique to your own project needs.
Why is a Project Charter so Important and Necessary?
Okay, now that we’ve seen specifically what a Project Charter is, we need to circle back and answer the question of why it’s actually needed. There are three parts to the answer to this question:
Management of Expectations. A Project Charter is your first and most important opportunity to manage peoples’ expectations. We all know that until something is written down and signed off on by relevant parties… well, it’s not real. Getting the fundamental Why’s, What’s, How’s, and Who’s written down on paper and approved means that you’ve defined the high-level goal posts of the project. You understand—and your key stakeholders also know—what you’re getting into. You know what big-picture “success” is supposed to look like at the end of the project. As Stephen Covey once wrote, “begin with the end in mind.” Your Project Charter defines that end.
Requirements Flow-Down and Traceability. Those of you that know me are probably rolling your eyes at this one, but I don’t care. Your job is as the PM is to deliver the deliverable within its specified quality requirements. Under-delivering is obviously bad—but so is over-delivering. The truth is this: Better, Different, and/or Perfect are all the Enemy of Good Enough. Your job as PM is to keep your eye on “good enough” as your target. And defining good enough starts with the Project Charter, from which the final versions of all other documents and requirements should flow. Without a Charter, you simply can’t finalize all other specification and requirement documents and know that they meet the definition of “good enough.”
Decision Making Tool. You will run into difficult situations and decision points when managing your project; this is part of being a project manager and ultimately why you’re the one who is paid the big bucks. Even the most basic and simple of projects can create challenging issues that you as PM must orchestrate the solutions to. The very first place you must go when presented with these proverbial “forks in the project road” is your Project Charter. This is the beacon that you have to keep in your view sight. It’s the end goal you’re steering toward as the manager of a project, and having a Charter to refer to will make that process much easier. If Path A gets you closer to achieving the case spelled out in the Project Charter than Path B does… well, this should be a big hint as to which fork in the road take.
When is a Project Charter Needed?
This one should be obvious by now, but let’s state it for the record: One of—if not the —very first things you need to create is the Project Charter. Sometimes, this document is actually created by others before you’re even hired as the PM, while other times you must create it from scratch when you come on board. But it’s still absolutely necessary in either case.
A Project Charter is a key output of the initiation stage or phase of a project. Without this document available right from the start, you are essentially beginning the road trip of your project without a map. Do not skip this step!
How to Write a Project Charter
As we said above, there is no one-size-fits-all approach to a Project Charter. Templates can only get you so far. Every project is unique, and so will be its Charter.
I suggest beginning with the six basic categories listed above (Executive Summary, What’s, How’s, Who’s, Other Key Information, Appendices & Link), including their sub-categories. Brainstorm these categories with other key personnel, stakeholders, and interested parties. Get their input and write it down. Mind map it. Collect and sort and group common elements.
Then create a draft charter that you like—and then circulate it for comment. Call meetings to discuss key aspects of it with key personnel. You’re writing a founding document, so this process can’t be rushed. Spend the appropriate time and get the Charter right; your job as a PM depends upon it.
Oh, and after you’ve written, re-written, and finalized the Charter, it’s time to get the relevant and appropriate parties within your organization (and your key external stakeholders and/or customer, too) to literally sign off on the document. Get their approvals in writing. Doing this essentially puts your project goal posts under configuration control—which means the project goal posts will be that much more resistant to change once the actual work is underway.
Is the Project Charter A Static Document?
The short answer to this is both yes and no. Once you start a project, you will undoubtedly learn much more about the project, what’s possible, what’s not, how much the project is actually going to cost in terms of money and time, what additional important stakeholders are becoming involved in the project, and so on. In this respect, the Project Charter is sometimes a dynamic document in the early stages of a project. But as time goes on, the ability to change and update the Charter necessarily gets more and more difficult. In fact, if at all possible, you should lock down the Charter immediately and resist changes to it unless they are vitally important.
Said another way, Project Charters can and are often re-opened for editing and updating early in the project, but don’t let this linger. And any changes should be done through a very rigorous and formal process. Sometimes, this process is accompanied by an actual re-baselining of the project. In other words, all relevant parties have a say in any post-start project “moving of the goal posts.”
No one expects the author(s) of a Project Charter to know everything up front before a project begins, but they do expect the Charter to outline and define the big, broad strokes of a project. Get these approved, signed-off, and under configuration control. If more detailed and relevant information is uncovered as the project kicks off—and is required in the Charter—there are opportunities to do so. At some point, however, usually, by the time procurement and fabrication efforts are underway, the Project Charter becomes nearly impossible to change, as the project itself will be well understood and on its way toward ultimate successful completion.
The Bottom Line:
A Project Charter is arguably the single most important—and yet often overlooked—document in a project. You need this document now! What are you waiting for?