Most people meet the five process groups as a list to be memorized: Initiating, Planning, Executing, Monitoring and Controlling, Closing. Learned that way, they feel like bureaucratic labels. Understood properly, they are something much more useful — five different questions a project manager is always answering, and knowing which one you are on tells you what to do next.
This guide explains what each group is genuinely for, follows a single real project through all five from first conversation to final handover, and clears up the misconception that causes more confusion than any other: process groups are not project phases.
The five process groups at a glance
All 49 processes in the framework belong to exactly one of these five groups. The counts are lopsided on purpose — they tell you where the real work of managing a project sits:
| Process group | Processes | The question it answers | What you have when it is working |
|---|---|---|---|
| Initiating | 2 | Should we do this at all, and who says so? | An approved charter and a stakeholder register |
| Planning | 24 | How exactly will we do it? | Approved scope, schedule and cost baselines |
| Executing | 10 | Are we doing it? | Actual deliverables |
| Monitoring and Controlling | 12 | Are we doing it right, and what do we do about the gap? | Accepted deliverables and approved changes |
| Closing | 1 | Are we genuinely finished? | Closed contracts and archived records |
Notice the shape: Planning holds 24 of the 49 processes — close to half — while Closing holds exactly one. That is not an accident of bookkeeping. It reflects a real claim about projects: the leverage is in deciding how you will work before you commit money to it, and the failure mode is skipping that to start “making progress.”
One project, all five groups
Abstract definitions of the process groups are forgettable, so here is a single project we will carry all the way through. Northwind Logistics is consolidating two aging offices into one new headquarters — 240 staff, a fixed lease-expiry date fourteen months out, a fit-out, new network cabling, furniture, and a move weekend that cannot overrun. It is deliberately not a software project: the process groups are industry-neutral, and a physical project makes the boundaries between them easier to see.
1. Initiating — 2 processes
Initiating exists to answer one question: does this project have legitimate authority to exist, and who has a stake in it? It is the smallest group — just 2 processes — but skipping it is how projects end up with a manager who has responsibility and no authority to spend, or a stakeholder who surfaces in month nine with a veto.
At Northwind
At Northwind, the trigger is the lease. The COO asks a facilities director to look at options; a business case comes back showing consolidation saves 22% in annual occupancy cost. Initiating is the moment the COO signs the charter — naming a project manager, setting a budget envelope of $4.1M, and stating the constraint that the building must be occupied before the lease ends.
The second half is finding out who matters. The obvious names are Facilities, IT and HR. The less obvious ones — the city permitting office, the landlord of the building being vacated, the department heads who will fight over floor allocation, and the 240 employees whose commutes are about to change — are exactly the ones that derail projects when discovered late.
The 2 processes in this group
You know this group is working when: Someone with real budget authority has signed something, and you have a written list of who has a stake and how much influence each one holds.
2. Planning — 24 processes
Planning is the group that decides how the work will be run — and it is enormous because it covers every dimension of the project at once, not just the schedule. There is a planning process for scope, schedule, cost, quality, resources, communications, risk, procurement and stakeholders, and for most of those you first plan how you will manage the area, then do the detailed planning inside it.
The output that matters is the set of baselines: an approved scope, schedule and cost that you will later measure reality against. Without baselines there is no meaningful sense in which a project can be “behind” — you would have nothing to be behind.
At Northwind
Northwind’s planning starts with scope, and the discipline is as much about exclusions as inclusions. In: fit-out, cabling, furniture, the physical move. Out: the ERP migration that a department head keeps attaching to the project. Writing that exclusion down is what makes it defensible in month seven.
The schedule is built backwards from the immovable lease-expiry date, which immediately exposes the critical path: permits, then long-lead millwork, then cabling, then furniture, then the move weekend. Cost planning turns the $4.1M envelope into a real budget with contingency. Risk planning identifies the one that would actually sink the project — a permit delay compressing everything downstream — and assigns a response: file six weeks early, and pre-qualify a second general contractor.
Procurement planning decides what is bought rather than done in-house (general contractor, movers, AV vendor) and communications planning settles how 240 people will hear about a move that changes their daily lives.
The 24 processes in this group
- Integration: Develop Project Management Plan
- Scope: Plan Scope Management · Collect Requirements · Define Scope · Create WBS
- Schedule: Plan Schedule Management · Define Activities · Sequence Activities · Estimate Activity Durations · Develop Schedule
- Cost: Plan Cost Management · Estimate Costs · Determine Budget
- Quality: Plan Quality Management
- Resource: Plan Resource Management · Estimate Activity Resources
- Communications: Plan Communications Management
- Risk: Plan Risk Management · Identify Risks · Perform Qualitative Risk Analysis · Perform Quantitative Risk Analysis · Plan Risk Responses
- Procurement: Plan Procurement Management
- Stakeholder: Plan Stakeholder Engagement
You know this group is working when: Scope, schedule and cost baselines are approved, and you could hand the plan to another manager and have them run it.
3. Executing — 10 processes
Executing is where the plan meets the world and where nearly all the money is spent. Its 10 processes split into two kinds of work: producing the deliverables, and running the people and vendors who produce them. A striking share of a project manager’s executing effort is the second kind — acquiring and developing a team, managing communications, managing stakeholder engagement, conducting procurements.
At Northwind
The general contractor mobilizes on site. Cabling crews work nights. The AV vendor is contracted and scheduled around the millwork. The project manager spends far less time on construction than on keeping people aligned: a weekly site walkthrough, a fortnightly steering update to the COO, and a running communications campaign so that 240 employees know their new desk, their new commute and their move-weekend instructions before they have to ask.
This is also where the risk responses planned earlier get implemented rather than admired — the early permit filing actually happens, and the backup contractor is actually pre-qualified.
The 10 processes in this group
- Direct and Manage Project Work
- Manage Project Knowledge
- Manage Quality
- Acquire Resources
- Develop Team
- Manage Team
- Manage Communications
- Implement Risk Responses
- Conduct Procurements
- Manage Stakeholder Engagement
You know this group is working when: Deliverables physically exist, and the people doing the work know what is expected of them this week.
4. Monitoring and Controlling — 12 processes
Here is the thing to internalize: Monitoring and Controlling does not come after Executing. It runs continuously, alongside everything else, from the moment there is a baseline to measure against until the project closes. That is why it is the second-largest group with 12 processes — there is a control process shadowing nearly every planning process.
The group does two distinct jobs. It measures — comparing actual scope, schedule, cost and quality against the baselines. And it decides — routing every proposed change through integrated change control so that the plan is amended deliberately rather than eroded quietly.
At Northwind
Two moments at Northwind show the group working. First, a department head asks to add a wellness room to the fit-out. That is not a conversation, it is a change request: costed at $180K and eleven days, submitted to the change control board, and in this case approved with the contingency drawn down and the baseline formally updated. The alternative — a verbal yes on a site walk — is precisely how projects lose control of scope.
Second, the permit does slip, by three weeks. Because cost and schedule are being tracked against a baseline, the variance is visible within days rather than at the end. The response is a documented re-plan: overtime on cabling to recover two weeks, and the move weekend held firm because it is the one date that cannot move.
Near the end, formal acceptance happens here too — the punch-list walkthrough where the client signs off each completed area is a control process, not an executing one.
The 12 processes in this group
- Monitor and Control Project Work
- Perform Integrated Change Control
- Validate Scope
- Control Scope
- Control Schedule
- Control Costs
- Control Quality
- Control Resources
- Monitor Communications
- Monitor Risks
- Control Procurements
- Monitor Stakeholder Engagement
You know this group is working when: Every variance from the baselines is known, and each one has either been corrected or consciously accepted.
5. Closing — 1 process
Closing is a single process, and it is the one most often skipped — usually because the team has already been reassigned to the next thing. Its purpose is to make the ending formal: contracts settled and closed, final acceptance obtained, records archived, resources released, and lessons captured while they are still fresh.
At Northwind
Northwind’s move weekend succeeds, and the temptation is to call it done on Monday. Closing is the unglamorous fortnight after: final payment and retainage released to the contractor once the punch list clears, the vacated lease formally terminated, warranty documentation handed to the Facilities team who will own the building from now on, and a lessons-learned session that records the single most valuable fact the organization now owns — permits in this city take six weeks longer than the contractor estimated. That one line saves the next project more than the retainage was worth.
The 1 process in this group
You know this group is working when: Contracts are closed, records are archived, operations owns the result, and nobody is still informally working on it.
The big misconception: process groups are not project phases
This trips up more exam candidates and new managers than anything else on the topic, so it is worth stating plainly. A phase is a chunk of the project. A process group is a type of work. They are different axes, and one does not map onto the other.
Three consequences follow, and each one is a common exam trap:
- The groups overlap in time. Executing and Monitoring and Controlling run simultaneously for most of a project’s life. You do not finish controlling and then start executing.
- They repeat. Northwind re-planned mid-execution when the permit slipped — that was genuine Planning-group work happening in month eight, not a failure of the original plan.
- They recur per phase. A project delivered in three releases runs Initiating through Closing within each release, then closes the project as a whole. In iterative and agile delivery this is the norm: every iteration plans, executes, controls and closes, at a smaller scale.
The clean way to hold it: a project has phases on the calendar, and every phase contains a mix of all five kinds of work. If a scenario question describes a manager “in the Executing phase,” read it as shorthand — the useful question is always which kind of work does this situation call for?
How the groups relate to the knowledge areas
Process groups are only one axis of the framework. The other is the knowledge area — the discipline a process belongs to, such as scope, schedule, cost, quality, risk or procurement. Every process sits at one intersection of the two: Estimate Costs, for example, is Planning work in the Cost knowledge area.
The two axes answer different questions. The process group tells you when in the flow of work something happens; the knowledge area tells you what discipline it draws on. Learning the grid formed by both is the single highest-value thing you can do for exam recall — which is the subject of our guide to memorizing the 49 processes.
It is also worth knowing that the process view is not the only way the profession frames project work. A complementary model organizes the same reality into performance domains — outcome-oriented areas of focus rather than discrete processes. The two views are not competitors; the processes tell you what to do, and the domains tell you what good looks like.
Frequently asked questions
What are the 5 process groups in project management?
The five process groups are Initiating (2 processes), Planning (24), Executing (10), Monitoring and Controlling (12) and Closing (1). Together they account for all 49 processes. Each group represents a type of project work — authorizing, planning, doing, checking and finishing — rather than a block of time on the calendar.
Are process groups the same as project phases?
No. A phase is a segment of the project timeline; a process group is a category of work that can occur in any phase. Executing and Monitoring and Controlling overlap for most of a project, planning recurs whenever circumstances change, and in iterative delivery every single iteration runs through all five groups.
What is the difference between process groups and knowledge areas?
Process groups describe when work happens in the flow of a project; knowledge areas describe what discipline the work belongs to, such as scope, cost or risk. Every process belongs to exactly one group and one knowledge area — for instance, Determine Budget is a Planning process in the Cost knowledge area.
Which process group has the most processes?
Planning, with 24 of the 49 processes — close to half the framework. Monitoring and Controlling is second with 12. Closing has only 1. The imbalance reflects where a project manager’s leverage genuinely lies.
Do the process groups happen in a strict order?
They begin in a logical order — you cannot plan a project that has not been authorized — but they do not run as a strict sequence. Planning is revisited throughout, Monitoring and Controlling runs continuously alongside Executing, and each phase of a large project cycles through the groups again.
Next steps: keep the complete 49-process cheat sheet as your reference, use the memorization method to get the grid into long-term recall, or browse all 49 processes to see the inputs, tools and outputs behind any one of them.
In the Eighth Edition
This article describes the framework as set out in the Sixth and Seventh Editions. The Eighth Edition reorganized it into 6 principles, 7 performance domains and 40 processes.