PMBOK Initiating Process Group: The Project Charter, Stakeholders and Free Templates
The initiating process group is where a project formally begins. Its job is to answer two questions: should we do this, and who has a stake in it? In the PMBOK Guide, Sixth Edition, the group has two processes: developing the project charter and identifying stakeholders. This guide explains both, gives a project charter template and a stakeholder register, and shows how the ideas apply in the latest edition and in agile work.
What the initiating process group is
Open-textbook material based on the PMBOK Guide, Sixth Edition, describes the initiating process group as the processes that define a new project or a new phase of an existing project by obtaining authorization to start it (see Abdullah Oguz’s open textbook Project Management, chapter 1.5).
Two points matter:
- It is a group of processes, not a phase. The group can be used at the start of a project and again at the start of each phase. See the 5 phases of project management for why the difference matters.
- It gives authority. Until a project is formally authorized, nobody is sure who is in charge, what is wanted or whether resources will be available.
A note on PMBOK editions
The PMBOK Guide has changed over time. The Sixth Edition (2017) is the one organized around five process groups, and it is still widely referenced in study materials. The Seventh Edition (2021) moved to principles. The Eighth Edition was published in November 2025.
On its PMBOK Guide page, PMI says the Eighth Edition retains the principles and performance domains foundation of the Seventh Edition, with six core principles and seven performance domains, and reintroduced process guidance “presented in an evolved, non-prescriptive way.” The page does not describe the five process groups by name, so we cannot tell you from it how the Eighth Edition labels the start of a project.
The practical advice is the same in any edition: confirm the purpose, get authority, and know your stakeholders before you plan. The details below follow the Sixth Edition, which is still widely referenced. If you are studying for an exam, check which edition and content outline it follows. See the PMP exam prep course guide.
The two initiating processes
| Process | Purpose | Main inputs | Main outputs |
|---|---|---|---|
| Develop Project Charter | Create the document that formally authorizes the project and gives the project manager authority. | Business documents, agreements, enterprise environmental factors, organizational process assets | Project charter, assumption log |
| Identify Stakeholders | Find the people and organizations affected by or able to affect the project, and record what matters about them. | The project charter, project documents, agreements and similar inputs | Stakeholder register |
The charter inputs and outputs follow the open textbook above, and the stakeholder register is the standard output of identifying stakeholders. Exact inputs and tools differ between editions, so check the edition you use.
Two terms from the table:
- Enterprise environmental factors: conditions outside the project team’s control, such as regulations, culture and market conditions.
- Organizational process assets: the organization’s own templates, policies and past project records.
The project charter
The project charter is a short document that says a project exists and who is responsible for it. The open textbook calls developing it the starting point for all projects, regardless of industry, size or complexity.
What the charter does
- Names the sponsor and the project manager and gives the manager authority to use resources.
- States the purpose: the problem or opportunity.
- Sets high-level goals and success measures.
- Defines high-level scope, key deliverables and boundaries.
- Records assumptions, constraints and major risks.
- Gives rough time and cost expectations and key milestones.
Charter vs. business case vs. project plan
| Document | Question it answers | Detail level |
|---|---|---|
| Business case | Is this worth doing, and why? | Analysis of benefits, costs and options. An input to the charter. |
| Project charter | Are we authorized to do it, and who is in charge? | High-level, often one to two pages. |
| Project management plan | How will we do it? | Detailed. Created in planning. |
The “one to two pages” is a common rule of thumb, not a requirement. Keep it short enough that sponsors actually read it.
Project charter template
This is our own template, based on the typical contents above. Adapt it to your organization.
Project charter: [project name]
Date: [date] · Version: [number]
1. Purpose: [The problem or opportunity in one or two sentences. Why now?]
2. Objectives and success measures: [Measurable outcomes, e.g., reduce X from A to B by date.]
3. High-level scope: In: [list] · Out: [list]
4. Key deliverables: [List]
5. Summary milestones and timeline: [Start, major milestones, target finish]
6. Budget estimate: [Rough range and funding source]
7. Assumptions: [Things you believe are true but have not confirmed]
8. Constraints: [Fixed dates, budget limits, regulations, technology]
9. Major risks: [Top three to five]
10. Key stakeholders: [Names and roles]
11. Project manager and authority level: [Name; what the manager can decide and spend]
12. Approval: Sponsor [name, signature, date]
Tip: write the success measures first. If the sponsor cannot say what success looks like in a sentence, stop and fix that before you plan.
Identifying stakeholders
A stakeholder is anyone who is affected by the project or who can affect it. The list is wider than most teams expect. Think in groups:
| Group | Examples |
|---|---|
| Sponsors and decision makers | Executives who fund the project and approve changes. |
| Users and customers | People who will use the result or pay for it. |
| Team and managers | Project team, functional managers who lend people. |
| Suppliers and partners | Vendors, contractors, other organizations. |
| Control functions | Legal, compliance, finance, security, procurement. |
| Community and regulators | Neighbors, public bodies, industry regulators. |
Sort them: power and interest
A simple and widely used grid sorts stakeholders by how much power they have over the project and how interested they are. This is a common technique, and the labels below are our summary.
| Low interest | High interest | |
|---|---|---|
| High power | Keep satisfied: brief updates, no surprises. | Manage closely: involve them in key decisions. |
| Low power | Monitor: minimal effort. | Keep informed: regular updates, listen to feedback. |
Stakeholder register template
The stakeholder register is the standard output of this process. Start it now and keep updating it. See also project team roles and responsibilities.
| Name / group | Role | Main interest or concern | Power | Interest | Current attitude | How we engage |
|---|---|---|---|---|---|---|
| [Name] | Sponsor | Return on investment | High | High | Supportive | Weekly 15-minute update |
| [Name] | Department head | Disruption to daily work | High | Medium | Cautious | Early meeting; agree change plan |
| [Group] | End users | Ease of use | Low | High | Unknown | Interviews; test sessions |
The sample rows are placeholders. Be careful with the “attitude” column. It is a working note, so keep the register private to the project team.
Go or no-go: deciding to start
Initiating is also the last cheap chance to say no. Before authorizing, check:
- Is the problem or opportunity clear and important?
- Does it fit the organization’s priorities?
- Is the expected value larger than the likely cost and risk?
- Is there a sponsor who will fund it and remove obstacles?
- Are people with the right skills available?
- Do key stakeholders agree on what success means?
A project that fails these checks is better stopped, reshaped or postponed than started and abandoned later. Read why projects fail for common causes.
A worked example
This is a made-up company, but the pattern is common. A 60-person firm wants to replace its outdated website.
| Charter element | Entry |
|---|---|
| Purpose | The current site loads slowly and cannot be updated without a developer. Leads from the site have fallen for two years. |
| Objectives | Launch by 30 June. Pages load in under 3 seconds. Staff can edit content without a developer. Return leads to last year’s level within six months. |
| Scope | In: design, content migration, contact forms, analytics. Out: new product features, a mobile app. |
| Budget | Range approved by the managing director; contingency of 10 percent. |
| Assumptions | Marketing can supply new copy by 15 March. Existing hosting can be reused. |
| Risks | Late content, an unclear approver, search ranking loss on launch. |
| Sponsor / PM | Managing director / marketing manager. |
While identifying stakeholders, the team realizes that the sales team (who use the leads), IT (who run hosting) and legal (who review the privacy notice) were not on the original list. Adding them now avoids three late surprises. Notice how the measurable objectives make later scope arguments easier to settle. See project scope creep.
Initiating in agile and hybrid projects
Agile teams still need a reason to exist, sponsors and a list of people who matter. They usually do it with lighter documents. Our summary of common practice:
| Traditional initiating output | Typical lighter equivalent |
|---|---|
| Project charter | A one-page vision or product brief, plus a team agreement on working methods. |
| Stakeholder register | A stakeholder map and a rhythm of demos and reviews. |
| Detailed scope | A prioritized list of goals or backlog that will change. |
The principle is the same: be clear about value and authority before you build. The depth of paperwork should fit the project’s size and risk. Read how agile is spreading in the use of agile project management.
Common mistakes
- Starting without a charter. Work begins, and nobody has authority.
- Vague goals. “Improve customer experience” cannot be measured.
- Writing a long charter nobody reads. Keep it high level.
- Forgetting stakeholders. Late discoveries are expensive. Review the register often.
- No named sponsor. A project without a sponsor is an orphan.
- Confusing the charter with the plan. Save detail for planning.
- Treating initiation as a formality. This is where you can still say no.
Next, see the PMBOK planning process group. For more habits that help projects succeed, read 15 project management habits.
Frequently asked questions
What is the initiating process group?
It is the PMBOK process group that defines a new project or phase and obtains authorization to start it.
What processes are in the initiating process group?
In the PMBOK Guide, Sixth Edition: Develop Project Charter and Identify Stakeholders.
What is a project charter?
A short document that formally authorizes a project, names the sponsor and project manager, and sets out purpose, objectives, high-level scope and key constraints.
Who writes the project charter?
Often the project manager or sponsor drafts it, with input from stakeholders. The sponsor or another authorizing person approves it.
What is the stakeholder register?
A record of the people and organizations involved, their interests, influence and how you plan to engage them. It is the standard output of identifying stakeholders.
What is the difference between a business case and a project charter?
The business case explains why the project is worth doing. The charter authorizes it and names who is in charge. The business case is an input to the charter.
Is the initiating process group still used in the latest PMBOK Guide?
PMI’s page for the Eighth Edition (November 2025) does not mention the five process groups by name, though it says process guidance was reintroduced in a non-prescriptive way. The activities remain good practice, and the Sixth Edition is still widely used in study materials.
Browse certificate, course and degree programs side by side.