5 Project Management Process Groups Explained (2026 Guide)

Project management process groups are PMI’s logical groupings of project management processes by purpose. Each group collects the processes that start, plan, perform, check, or close a project or one of its phases.

Each group has an output, an owner, and a condition that tells you it is finished:

During the initiating process group, you write the charter, build the stakeholder register, and test the business case. The project charter authorizes the work and lets you assign people and spend against the budget.

Initiating is finished when four documents exist and the project sponsor has signed the first one:

In Productive, save the project charter and stakeholder register as a reusable doc template. Apply it to a doc inside each new project, and every project member can open it.

During the planning process group, you turn the charter into the scope baseline, schedule, cost baseline, and risk register. It follows initiating because you need approved project objectives and a named project sponsor before committing dates and money.

Planning is the largest group, with 24 of the 49 processes in PMBOK 6.

The project scope baseline is three documents: the scope statement, the work breakdown structure (WBS), and the WBS dictionary. The WBS comes from decomposition, one of PMBOK’s tools and techniques.

You break each deliverable into work packages small enough to estimate and assign.

The schedule comes from four steps in project schedule management: define activities, sequence them, estimate durations, and build it. The finished schedule sets the project milestones your weekly updates report against.

The cost baseline is the approved, time-phased budget you measure spend against. After risk analysis, the risk register lists each project risk with an owner and a planned response.

The project management plan combines every planning output into one approved document. That includes the plans for quality, resources, project communications, procurement, and stakeholder engagement.

Planning is done when the project sponsor approves the baselines.

During the executing process group, you assign the tasks, bring in subcontractors, run quality checks, and process approved changes.

Here’s what each activity looks like:

Assign work from the WBS, one owner per work package. Mark a task at risk if it has no logged hours five days after its scheduled start. Send stakeholders a fixed weekly update covering deliverables completed, spend against the cost baseline, and open risks.

Check each deliverable against the quality plan before the client sees it. Sign each subcontractor’s contract before their work starts, and track their invoices against the cost baseline.

Route every scope change through a written change request. The team starts the change only after the project sponsor signs and the schedule and budget are updated. When an approved change moves a task, Productive’s Gantt layout shifts every task waiting on it.

You monitor and control a project by comparing actual hours, spend, and dates against the baselines each week. Each gap then gets one response: a corrective action, a change request, or a new forecast.

Monitoring and controlling runs from kickoff to closing, alongside every other project management activity. It holds 12 processes in PMBOK 6, including Control Scope, Control Costs, Monitor Risks, and Validate Scope.

Validate Scope is where the client formally accepts each finished deliverable. Get written acceptance for each deliverable as it finishes. A rejection found at project end leaves no time for rework.

Earned value management (EVM) puts cost and schedule progress on one scale. It compares the budgeted value of completed work with its actual cost and with the work planned by now.

A CPI (cost performance index) below 1.0 means you are over budget. An SPI (schedule performance index) below 1.0 means you are behind schedule. Example: work budgeted at 80 hours that took 100 logged hours gives a CPI of 0.8.

Update the risk register weekly: close retired risks, add new ones, and name an owner for each. Keep it in your project management software, linked to the tasks each risk owner already works on.

During project closing, you confirm final client acceptance, close contracts, and archive one project record. Settle subcontractor claims and purchase orders, then raise the final invoice against unbilled budget.

Release remaining bookings, run a lessons learned session, and close the project so no one can log more hours. In Productive, delivering a budget locks it against further time and expense tracking. The same step can remove its future bookings.

The process groups depend on each other because each one starts from outputs another group produced. Monitoring and controlling runs alongside all of them. Two parts of that dependency matter most: what each group hands to the next, and who owns each handover.

Those handovers are how you catch an overrun early in end-to-end project management. A project charter signed in week one sets the budget ceiling execution burns against.

A variance then shows up in the weekly status report instead of on the final invoice.

Initiating hands planning a signed project charter and a stakeholder register, so the scope baseline starts from approved objectives. Planning hands executing the schedule, cost baseline, and risk register the team assigns work against.

Executing hands monitoring logged hours and spend, and hands closing the accepted deliverables and any unbilled budget. Monitoring feeds corrective actions back into the plan while the work is still running.

Written handovers matter most in hybrid work management, where the next owner may not share your office.

Name one person per handover in the project management plan, never a team. The project manager owns the charter into planning. The delivery lead owns the schedule into executing, and the account lead owns accepted deliverables into closing.

A handover is complete when the receiving owner confirms they have the document and no open questions. Review any open handovers in the weekly status meeting.

No, process groups are not project phases. A phase is a stretch of the project life cycle, such as discovery, design, or build. Each phase runs its own pass through all five groups, so a three-phase project initiates and closes three times. PMI’s 8th edition covers phases and Focus Areas in separate sections of its project life cycle chapter.

Closing repeats at the end of every phase. PMBOK’s Close Project or Phase runs each time a stage finishes, and again when the project life cycle ends. The next phase opens with its initiating work: a short project charter, a plan, and a business case check.

Example: a website redesign runs in discovery, design, and build phases. Discovery closes with a signed research summary and a decision to fund design. Design opens with its own scope, schedule, and budget, checked against what discovery found.

Treat the groups as one pass, and you approve the budget once and check it at the end.

Process groups and knowledge areas connect through the individual processes. In PMBOK 6, every process belongs to one group and one of 10 project management knowledge areas.

The group tells you when to run a process; the knowledge area tells you which discipline it draws on. Each process also lists its inputs, tools and techniques, and outputs.

All 10 areas appear in planning and in monitoring and controlling. That is why those two groups hold 36 of the 49 processes.

The five process groups work only as well as the handovers between them. Split the project charter, schedule, logged hours, and invoice across separate tools, and every handover becomes re-entry.

The approved budget gets retyped into a spreadsheet, and nobody can compare burn against plan without an export. If you want bookings, logged time, and invoices tied to one budget, book a demo of Productive.