If you were to do an examination of some of your past projects and their overall performance, you would more than likely discover what I did when I decided to do this exercise. We should have known we were going to be in trouble from the get-go, and that was right at the beginning when the project charter was crafted. So, for your next project, give the project charter a closer look. Is it really guiding your project success?
The project charter is defined by PMI® as the document which is an output of the initiation phase of the project, it authorizes the project to proceed within the organization. For some, the problem starts with a lack of clear understanding of this document’s importance linked to it being called several things depending on the organization, such as a project brief, project letter of intent, project overview document, project mandate, and sometimes project case. Most of these are all one of the same. Right away, this does not help clarify anything. Whatever naming convention is used, you need to ensure that the document does what it is intended to do.
Another issue to clear up before we discuss what a project charter should include is the consideration as to whom this document “belongs” and where it should originate from. There are some back and forth discussions about this particular subject. From a practical standpoint, most PMs that I know, including myself, will tell you that they have had to create the charter as part of the ramping up of the project so they can then have the kick-off meeting, which formalized the launch process.
According to PMI®, the charter is actuality owned by the project sponsor, and he/she should be completing it with the help of subject matter experts to provide some of the technical details. While the sponsor is ultimately responsible for its preparation, it is rare in most people’s opinion that they create it rather than the proposed PM supported by experts who have the appropriate knowledge and necessary information for proper analysis.
At the end of the day, this document is a must for all projects, and some careful consideration should be given to its content and delivery. In most organizations, we will take information from a business case generated from the business unit requiring the work to be completed and prepare the charter, where we are then switching to project management terms as to how the work will be done and with what considerations.
This document is not meant yet to give every detail of a project, it is a 10,000 feet view of the project gathered from the stakeholders and put into terms that will get the PM and his/her team to start their way into formal planning. Formal planning with a delivery of a project management plan including several subsidiary plans is meant to provide the living, breathing, finer detailed information that will guide our project execution.
Good charter templates will include the following information:
- Project title, description, proposal, and justification
- Measurable project objectives and success criteria
- High-level project requirements
- Starting assumptions and constraints
- High-level project description, including boundaries otherwise known as in/out of scope
- High-level risks
- Milestone schedule summary
- Summary budget
- Our understanding of who the stakeholders are for this project
- Identification of project sponsor and project manager
- Approval requirements
As you can see from the list above, we are identifying during initiation, based on the information provided by the business, what our understanding of the project is at this time prior to digging any further to come up with a plan that will include more fact-based information and detail. I have heard one of my sponsors once call this the executive summary for the project. Close… the early understanding of the project.
It is not rare, for example, in this document to find in the summary budget section a statement such as: “budget not to exceed,” which provides some funding limit consideration without any of the details being available for review. This makes sense, considering we have yet to do proper estimates and consolidate our data into a budget.
One note to carefully consider during the creation of this document is for the boundaries to be clearly identified to the stakeholders as early as possible. For some or most stakeholders, this is the first time they might see in writing what will be or not be done for the project, and it is their chance to make a case for the inclusion or exclusion of items. It is as important for the PM, if not more, to make perfectly clear to the stakeholders what the project is not going to deliver. Missing an item in this section can cost much more later when it must be dealt with by a change request.
Finally, I would like to discuss the format of this document for a moment. In recent years, I have seen all kinds of variations in formatting, going from a one-page charter to a fifty-page one. Although there is no one-size-fits-all, I would suggest that when looking at the size of your charter, it should be considered for what it is, a high-level justification. Going into too much detail already just makes for a lot of work to determine items that are prone to need modification when researched further during the planning process. In other words, just keep it simply simple.
A few things before I leave you today… always have a charter for every project as it gives everyone an indication of what we are proposing to do and formalizes this into a project for the organization. Although very tempting, stay away from too many details and keep it to an appropriate level, leaving the planning to make it more concrete for people.
Similar Content:
-
Project Charter template
-
4 Essential tips for creating a project charter
-
Creating a project charter for a Six Sigma project
