Now that we have covered quite a lot of ground about what a project is and what are its different areas, we are finally diving into the specifics of how to plan your projects in order to increase your chances of success. This article brings everything you need to know about developing a successful project charter, as well as several resources to help you get organized. Be for a small project to be run during a week or for a big project that will require several months, the techniques and resources I present here will provide a great foundation for your work.
Your project charter is the basis for your project plan. Best practices really point out that we should invest time at the start of the project to plan out the rest of the project. You are going to encounter people who are gonna say things to you like “what is all this talking about it and writing about it? Why don’t we just go do it?” When you take the time upfront to map out what it is you’re doing, things are much more likely to run smoothly. Also, it’s gonna be easier and cheaper to change your approach at the beginning, while you’re discussing the work, than it is when you’re in the middle of implementing the work. And that’s why we don’t skip the planning process!
Just to make things clear, the term project charter can assume two meanings:
- A strict one, where the project charter stands for the single document that formally gives authority to the project manager;
- A general one, where the project charter stands for the body of documents including the formal authority statements, statements or work, etc.
I will use the general one here and bring the project charter and the statement of work together. Why? Mostly to follow the official PMBOK guide. These minor theoretical differences don’t really affect the final output of producing the project charter.
What is a Project Charter and How To Build One
Once your project is approved by the authorities in your company, it is time to go down to work and start building some guidelines to better manage the project. The first document you want to create is the Project Charter.
The Project Charter is the document that formally announces the project and explains the different dimensions of its implementation. It empowers you and your stakeholders with an understanding of what the project will look like and what will be accomplished. Another important function of the project charter is to give the project manager the authority to use organizational resources to meet project objectives. Why is this last bit important? Because normally a project is not immediately known by everyone in an organization. It needs some time until it spreads out, and the project charter is the document with the information about the key players that need to be known and their respective powers and permissions.
With these two functions, the project charter is an indispensable document to have. While the formal authority involves, most of the times, just a statement of support from the sponsor or issuer and several signatures from important people, the breakdown of the different dimensions of the project can be a little bit more lengthy. Let’s go through the different sections of a project charter in more details.
The Different Sections of a Project Charter
The next sections (also called as statement of work by some books and experts) explain the different dimensions of the implementation of a project. They empower you and your stakeholders with an understanding of what the project will look like and what will be accomplished. This breakdown of the different dimensions of the project can be a little lengthy, but keep in mind that you shouldn’t include every detailed information here. This is a summary breakdown, not the final document of your project! So here are the most important sections to include next:
- Project Purpose Statement
- Project Scope Statement
- Project Deliverables
- Costs and Estimates
- Objectives
- Project Constraints and Risks
- Stakeholders
- Chain of Command
Let’s take some time to analyze each section in more details.
1. Project Purpose Statement
Purpose Statement of the Project establishes the why of the project. In order to write this down precisely, you should ask yourself and your team questions like “Why are you doing this project? What are the benefits? Which problems will it solve?”
2. Project Scope Statement
The Scope Statement is the section where you will create boundaries to the project. It is extremely common to add unnecessary details and tasks while running the project, and suddenly you find yourself without budget and far beyond the initial schedule. Defining the Scope Statement helps you to judge whether a task or a process is necessary for the project and whether it should be included.
The scope statement should describe the main activities of the project, and it should do so in a way that makes it easy to spot extra work added later on. Of course, you can add work during more advanced phases of the project, but it should always be contained within the project scope.
Apart from what the project wants to achieve, another part that should be included in the scope statement is the section “Project Exclusions”. This answers the question of what is not part of the project, and it’s important to ensure that your stakeholders understand what they are not getting.
Let’s think of an example. You are running a project to redesign the accounting and CRM software used by your company. While designing the documentation for the new software is likely to be included in the scope of your project, you may want to keep tasks such as organizing formal training sections to new hired staff out of the scope of it. This, however, might be included in another project.
Since all the cost, schedule, and resource projections are based on several assumptions about the scope, this section is of extreme importance and should be carefully described.
3. Project Deliverables
What is a deliverable? To put it simply, a deliverable is something you create in order to successfully complete your projects. It can be a piece of a product, or a process of a service that you are creating or redesigning. The inclusion of deliverables in your scope statement is very helpful to understand what it will take to create your product or service. It creates intermediate and final “checkpoints” that can be further broken down into more specific tasks and processes.
Here are some examples:
- A blueprint of a house is an intermediate deliverable for a construction company, while the house itself is a final deliverable.
- A document defining the specifications of a software is an intermediate deliverable, while the software itself is the final deliverable.
- A mapped flowchart of the current hiring process is an intermediate deliverable, while a restructured flowchart for a new hiring process is the final deliverable.
But remember: the statement of work is not the place to detail such deliverables. You mention them here, but their details should be defined in other, more specific documents.
4. Cost and Schedule Estimates
This is not about writing a final date and a limit cipher. That alone won’t do. Why? Because of what I already said: no project runs smoothly from start to end. If you expect your project to run without any drawbacks, it’s time to rethink your expectations.
The cost and schedule estimates must answer questions like:
- How flexible are the budget and schedule?
- How did you calculate the deadlines? And the budgets?
- Why did you set such budgets and schedules?
- Can you ask for more budget or time? Who should you ask?
- How will the budget and schedule be monitored?
We have specifically dealt with the questions of creating the schedule and estimating the budget in other articles. For now, I would like to highlight the importance of writing the answers to most of the questions above (even if just in simple terms). It’s best to write things down than to leave them open for interpretation, and we can avoid a lot of conflicts by clarifying the information about the schedule and the budget.
5. Objectives
The objectives define what it takes for the different parts of the project to be successful. They walk hand-in-hand with the deliverables, but include more information about what makes the deliverables successful. For example: a deliverable might be a movable part of a new machine being developed. An objective might be to develop such component under budget X or according to schedule Y.
Objectives should be specific and measurable, so you can actually check whether they are met or not. As an example, you can think of a yearly growth rate in sales as an objective of a project to create a marketing campaign. This is measurable, specific, and it can be linked to a schedule to help with better visualization of its progress.
6. Project Constraints and Risks
You must include the known project constraints in your project charter. What are the constraints you already know? Maybe it’s the date of conclusion, the number of people allocated to your project, the characteristics of your product, etc. This section should also contain the assumptions of your project: things and facts that you assume as true and on which you base estimations and plans. An example is the time allocation of your members: will they be exclusively allocated to the project or will they work in several projects simultaneously? Their availability is one of the primary assumptions that will drive the schedule calculation and the budget estimation of your project.
7. Stakeholders
We deal with stakeholders in more details in this article about how to manage them. After identifying them and collecting the necessary information, use this section to mention who are your stakeholders and what is their role in the project. Here are five major stakeholders that cannot be left out of your statement of work under any circumstances:
- Project manager
- Project team
- Sponsor
- Functional management
- Customer
Your project will probably have more, so make sure to mention all of them to give a clear idea of who is involved and impacted by your project.
8. Chain of Command
The chain of command establishes who reports to whom. In small projects, this might not be really relevant: the project manager is usually the authority and is the connection between the team and higher levels. However, in project that cross organizational boundaries, the chain of command becomes important.
Free Resource
You can access a template of a project charter here.