Project Initiation Documents and Templates
The Initiation Process Group is the first of the five PMBOK-defined project process groups. The initiation processes formalize the authorization to start a project or phase. Keep in mind that the process groups can apply to a project or a specific phase within a project. Take a look at the Project Life Cycle Reference section for more information.
At the start of a project, the project could be separated into multiple phases. For example, if the project is a rather complex project with many moving parts, the project could be broken into phases that bring up the core functions. Then, future functions could be incorporated as budget, schedule, and resources permit. Breaking a project into phases helps avoid the “big bang” release and reduces project risk in general.
At the beginning of a project, the Initiation processes link the project’s business needs to the project. Clear business goals and objectives are developed and tied to the justification for why the project is needed. Initial funding estimates are developed and the project team is chartered.
The project or phase scope is examined during the initiation stage, and key structural decisions are made about how the project or phase will be planned and executed.
Project Initiation Stage Major Outputs
There are two major outputs in the project initiation stage:
- A Project Charter
- A Preliminary Project Scope Statement — coming soon!
The Project Charter formally authorizes a project or a project phase. The Project Charter is best delivered at a project kickoff by the project sponsor so that the Project Manager is given explicit authority by the sponsor. In many cases, the Project Charter becomes a paper exercise. But a Project Charter can be very powerful if it is given the proper visibility, because it defines the roles and responsibilities within the project and aligns the project to the strategic goals and objectives of the organization.
Preliminary Project Scope Statement
A Preliminary Scope Statement provides a high level scope narrative. Usually, the requirements are not fully vetted at this point. They are more like business needs. The scope should include things that are specifically not in scope as well. For example, if the integration to a third-party tool is going to be included in a later phase, then the scope statement should identify that this is out of scope.