Chapter 1
Initiating Forms
1.0 INITIATING PROCESS GROUP
The purpose of the initiating process group is to authorize a project, provide a high-level definition of the project, and identify stakeholders. There are two processes in the initiating process group:
- Develop Project Charter
- Identify Stakeholders
The intent of the initiating process group is to at least:
- Authorize a project
- Identify project objectives
- Define the initial scope of the project
- Obtain organizational commitment
- Assign a project manager
- Identify project stakeholders
As the first processes in the project, the initiating processes are vital to starting a project effectively. These processes can be revisited throughout the project for validation and elaboration as needed.
The forms used to document initiating information include:
- Project Charter
- Stakeholder Register
- Stakeholder Analysis Matrix
These forms are consistent with the information in the PMBOK® Guide—Fifth Edition. Tailor them to meet the needs of your project by editing, combining, or revising them.
1.1 PROJECT CHARTER
The project charter is a document that formally authorizes a project or phase. The project charter defines the reason for the project and assigns a project manager and his or her authority level for the project. The contents of the charter describe the project in high-level terms, such as:
- Project purpose or justification
- High-level project description
- High-level requirements
- Project objectives and related success criteria
- High-level risks
- Summary milestone schedule
- Summary budget
- Stakeholder list
- Project approval requirements
- Assigned project manager, responsibility, and authority level
- Name and authority of the sponsor or other person(s) authorizing the project charter
Use the information from your project to tailor the form to best meet your needs.
The project charter can receive information from:
- Agreements (contracts)
- Statements of work
- Business case
It provides information to:
- Stakeholder Register
- Project Management Plan
- Scope Management Plan
- Project Scope Statement
- Requirements Documentation
- Requirements Management Plan
- Requirements Traceability Matrix
- Schedule Management Plan
- Cost Management Plan
- Risk Management Plan
The project charter is an output from the process 4.1 Develop Project Charter in the PMBOK® Guide—Fifth Edition. You can use the element descriptions in Table 1.1 to assist you in developing a project charter.
TABLE 1.1 Elements of a Project Charter
| Document Element | Description |
| Project purpose or justification | The reason the project is being undertaken. May refer to a business case, the organization’s strategic plan, external factors, a contract agreement, or any other reason for performing the project. |
| High-level project description | A summary-level description of the project. May include information on high-level product and project deliverables as well as the approach to the project. |
| High-level requirements | The high-level conditions or capabilities that must be met to satisfy the purpose of the project. Describe the product features and functions that must be present to meet stakeholders’ needs and expectations. This section does not describe the detailed requirements as those are covered in requirements documentation. |
| Project objectives and related success criteria | Project objectives are usually established for at least scope, schedule, and cost. |
| Scope objectives describe the scope needed to achieve the planned benefits of the project. An example you could use for a fundraising 10K run is “The event will provide a 6.2 mile course, and raise $1.2 million for the specified charity.” | |
| Success criteria is the course that is certified as a 10K course and over $1.2 million in collected pledges. | |
| Time objectives describe the goals for the timely completion of the project. For example, the run will take place in September of the current year. The success criteria is whether or not the run took place in September. | |
| Cost objectives describe the goals for project expenditures. An example is: “The cost for producing the run will not exceed $100,000.” Obviously the success criteria is determined by the total amount spent producing the event. | |
| There may be additional objectives as well. Some organizations include quality objectives, safety objectives, and stakeholder satisfaction objectives. | |
| High-level risks | The initial risks at a project level, such as funding availability, new technology, or lack of resources. |
| Summary milestone schedule | Significant events in the project. Examples include the completion of key deliverables, the beginning or completion of a project phase, or product acceptance. |
| Summary budget | The estimated range of expenditures for the project. |
| Stakeholder list | A list of people who have an interest and an influence on the project success. |
| Project approval requirements | The criteria that must be met for the project to be accepted by the customer or sponsor. |
| Assigned project manager, responsibility, and authority level | The authority of the project manager with regard to staffing, budget management and variance, technical decisions, and conflict resolution. |
| Examples of staffing authority include the power to hire, fire, discipline, and accept or not accept project staff. | |
| Budget management refers to the ability of the project manager to commit, manage, and control project funds. Variance refers to the variance levels that require escalation for approval or re-baselining. | |
| Technical decisions define or limit the authority of the project manager to make technical decisions about deliverables or the project approach. | |
| Conflict resolution defines the degree to which the project manager can resolve conflict within the team, within the organization, and with external stakeholders. | |
| Name and authority of the sponsor or other person(s) authorizing the project charter | The name, position, and authority of the person who oversees the project manager for the purposes of the project. Common types of authority include the ability to approve changes, determine acceptable variance limits, impact inter-project conflicts, and champion the project at a senior management level. |
1.2 STAKEHOLDER REGISTER
The Stakeholder Register is used to identify those people and organizations impacted by the project and document relevant information about each stakeholder. Relevant information can include:
- Name
- Position in the organization
- Role in the project
- Contact information
- List of stakeholder’s major requirements
- List of stakeholder’s expectations
- Potential influence on the project
- A classification or categorization of each stakeholder
The Stakeholder Register is a dynamic project document. The stakeholders, their level of influence, requirements, and classification are likely to change throughout the project. Initially you will not have enough information to complete the register. As the project gets underway you will gain additional information and understanding about each stakeholder’s requirements, expectations, and influence and the Stakeholder Register will become more robust.
Information in the Stakeholder Register should be tailored to meet the needs of the project. For example, some projects may have internal and external stakeholders while others may only have internal stakeholders. The following sample is just one approach to identifying and documenting stakeholder information.
The Stakeholder Register receives information from:
- Project charter
- Procurement documents
It is related to:
- Stakeholder Analysis Matrix
It provides information to:
- Requirements Documentation
- Quality Management Plan
- Communications Management Plan
- Risk Management Plan
- Risk Register
- Stakeholder Management Plan
The Stakeholder Register is an output from the process 13.1 Identify Stakeholders in the PMBOK® Guide—Fifth Edition
You can use the element descriptions in Table 1.2 to assist you in developing a Stakeholder Register.
TABLE 1.2 Elements of a Stakeholder Register
| Document Element | Description |
| Name | Stakeholder’s name. If you don’t have a name you can substitute a position or organization until you have more information. |
| Position | The position the stakeholder holds in the organization or enterprise, for example, programmer, human resources analyst, or quality assurance specialist. |
| Role | The function the stakeholder performs on the project team, such as testing lead, scrum master, or scheduler. |
| Contact information | How to communicate with the stakeholder, such as their phone number, email address, or physical address. |
| Requirements | High-level needs for the project and/or product. |
| Expectations | Main expectations of the project and/or product. |
| Influence | The degree of influence the stakeholder has on the project. This can be a narrative description or high, medium, or low influence. |
| Classification | Some projects may categorize stakeholders as friend, foe, or neutral; others may classify them as high, medium, or low impact. |
1.3 STAKEHOLDER ANALYSIS MATRIX
The Stakeholder Analysis Matrix is used to classify stakeholders. It can be used to help fill in the Stakeholder Register. The classifications of stakeholders can also be used to plan stakeholder engagement for groups of stakeholders.
The following example is used to assess the relative power (high or low) on one axis and the relative interest (high or low) on the other axis. There are many other ways to categorize stakeholders using a grid. Some examples include:
- Influence/impact
- Friend/foe
The needs of the project will determine if a Stakeholder Analysis Matrix will be helpful and, if so, what stakeholder aspects should be assessed. Use the information from your project to tailor the form to best meet your needs.
The Stakeholder Analysis Matrix receives information from:
- Project charter
- Procurement documents
It is related to:
- Stakeholder Register
The Stakeholder Analysis Matrix is a tool used in 13.1 Identify Stakeholders in the PMBOK® Guide—Fifth Edition.
