In this first out of five project management processes, the project is created and defined to the extent necessary to begin planning the project. This step involves the project setup, and ensures that the performing organization is clear about the purposes and priorities surrounding the project. There are usually certain issues that require setup, like funding or stakeholder issues.
This is a small but necessary step, and its importance is easily underestimated.
The Project Management Body of Knowledge (PMBOK) identifies only two processes within this phase.
- Develop Project Charter
- Identify Stakeholders
Developing the Project Charter
The Project Charter is the document which defines and authorizes the project. It outlines the organization’s vision for the project and the business case for it. Essentially it represents what the organization is thinking when creating the project and puts a foundation under the planning phase. It can contain the following things:
- Scope statement
A general scope statement which identifies the vision for what the project will accomplish. For example, the construction of a new commercial building could involve a certain number of offices, design to a certain standard, etc. It is a good idea to identify the key deliverables, but it is not the function of the project charter to identify all deliverables. It should be limited to the non-negotiable ones such as the submission of a design package for approval before construction commences. A final scope statement will be developed for the project during the planning phase, but the project charter can (and should) identify the scope of the project as envisioned when the project is created. - Milestones
Similar to the deliverables, the major milestones can and should be identified in the project charter but it is not the role of the project charter to list all milestones. A project charter should not contain a detailed schedule, but a description of the key milestones can aid in the communicating the project as envisioned by the organization. - Business case
A description of why the organization is undertaking the project is helpful to put everyone on the same page from the beginning. Business metrics such as expected profit or revenue, or required Return on Investment (ROI) can make it clear to the project management team what the expected benefit will be. Maybe there is a single problem that is being solved. Stating this explicitly can guide in decision making during the project. - Funding amount
Most projects start out with a funding level approved by the organization. Stating the amount in the project charter can establish the boundaries of the project and ensure that nobody thinks too big or too small. - Funding status
Funding always comes with conditions, even when a pot of money has been approved. I’ve seen projects that have a certain funding level approved but run into funding issues later on, for example,- money moves to a future fiscal year and ends up on other projects.
- there are no contingencies available when the cost escalates.
- it wasn’t actually approved to begin with.
- Success Criteria
Every project contains criteria for its success and the organization performing the project should identify these on a level “outside” the project (i.e. the project charter). There are usually primary success factors like paving a road that’s smooth, or developing a website that’s beautiful. But it’s the secondary success factors that are usually overlooked and present the bigger risk to the project. These might include providing enough compaction to the asphalt, or providing the correct underlying database. - Stakeholders
Although it is not the responsibility of the project charter to identify all stakeholders, it should identify the primary stakeholders who are integral to the project and under whose auspices the project was created. For the paving project, the land developer is the project sponsor and the city (local government) is a major stakeholder who should be addressed during the project charter. The primary objectives of each party should be identified so it is clear why the project has been created.
Identifying Stakeholders
This may seem like a duplication since I have included the identification of stakeholders as a part of the project charter, above. I do believe the primary stakeholders should be identified in the project charter. But the PMBOK contains stakeholder identification as the second of the two processes within the initiating phase, and I also agree that it is a good idea to conduct a stakeholder analysis to determine all of the stakeholders separately from the project charter.
Stakeholders come in many forms and have vastly different needs as it relates to the project. They can be:
- Supporters. For example, a county that will receive tax revenue from a new plant.
- Opposed. For example, local landowners who don’t like the plant in their back yard.
They can also have varying levels of support. You often don’t know how strongly they support or oppose the project until you consult with them. Many projects have run into trouble because assumptions were made about stakeholder interests that were not based on direct communication with those stakeholders.
Often the overall stakeholder position is complex because there are varying positions within the stakeholder itself. For example, the county that will receive tax revenue from a new plant could have a contingent of taxpayers who are strongly opposed, pulling the politicians in different directions than they originally state. It can also cause changes to the stakeholder’s position during the project. Therefore it is often advisable to analyze the underlying factors governing a stakeholder’s position, even for stakeholders that are supporters.
