A process group is a category of related activities that together move a project from start to finish. In project management, the term refers to one of five process groups defined by the Project Management Institute (PMI) in its PMBOK framework: Initiating, Planning, Executing, Monitoring and Controlling, and Closing. The term also has a distinct meaning in computing, where it describes a set of related processes in a Linux or Unix operating system. This article covers both uses.
The Five Project Management Process Groups
PMI organizes all project management work into five process groups containing a total of 49 individual processes. These groups are not phases with hard start and stop dates. They overlap, repeat, and run concurrently throughout a project’s life. Think of them as buckets of activity that a project manager draws from at different points depending on what the project needs.
Initiating
The Initiating process group is where a project is formally authorized. You define the high-level scope, identify the primary stakeholders, and establish why the project exists. The main output is typically a project charter, a short document that names the project’s objectives, constraints, and the person responsible for leading it. Without formal initiation, projects tend to drift forward without clear authority or boundaries.
Planning
Once a project is authorized, Planning is where the team figures out how to get it done. This is usually the most process-heavy group. You define the full scope of work, create a detailed schedule, estimate costs, secure a budget, and build plans for resources, quality, communication, and risk. The central output is the project management plan, which becomes the baseline you measure everything against later. Planning doesn’t happen once and stop. As new information surfaces during execution, you return to planning processes to update the plan.
Executing
Executing is where the actual work happens. The project team carries out the tasks outlined in the plan: building the product, writing the code, constructing the building, or delivering whatever the project promised. Effective execution means coordinating people and resources, managing stakeholder expectations, and ensuring quality standards are met as deliverables are produced. This group typically consumes the largest share of the project budget and timeline.
Monitoring and Controlling
This group runs concurrently with Executing. While the team is doing the work, you’re tracking progress against the project plan, measuring key performance indicators, and identifying any variances from the baseline. When something drifts off course (a task running late, costs exceeding estimates, scope creeping beyond what was agreed), this is where you perform root cause analysis and implement corrective or preventive actions. Monitoring and Controlling also manages the formal change control process, so no changes to scope, schedule, or budget happen without proper review and approval.
Closing
The Closing process group formally ends the project. Once all deliverables have been accepted, you finalize activities across all process groups, close out any procurement contracts, archive project documents, and capture lessons learned for future projects. Skipping this group is common but costly. Without a formal close, contracts linger, resources stay allocated, and valuable knowledge about what worked and what didn’t disappears.
How Process Groups Relate to Knowledge Areas
PMI also organizes project management into ten knowledge areas: scope, schedule, cost, quality, resources, communications, risk, procurement, stakeholder management, and integration. Each of the 49 processes sits at the intersection of one process group and one knowledge area. For example, “Estimate Costs” is a Planning process in the Cost Management knowledge area, while “Control Costs” is a Monitoring and Controlling process in the same knowledge area.
This matrix structure helps project managers locate the right tools and techniques for whatever situation they’re facing. If you’re in the middle of execution and costs are climbing, you know to look at the Monitoring and Controlling processes within the Cost Management knowledge area for guidance on corrective actions.
Process Groups in the Current PMBOK Edition
When PMI released the seventh edition of the PMBOK Guide, it shifted the core framework away from processes and toward eight performance domains, which are more flexible and support agile, hybrid, and predictive approaches. However, PMI didn’t abandon process groups. It published them separately in a companion resource called “Process Groups: A Practice Guide,” which contains the same 49 processes with their inputs, tools, techniques, and outputs. If you’re studying for the PMP exam or working on a project that follows a predictive (waterfall-style) approach, the process groups model remains the standard reference.
Process Groups in Linux and Unix Systems
In computing, a process group means something entirely different. On Linux and Unix-like operating systems, a process group is a collection of related processes that share a single process group ID (PGID). The PGID matches the process ID (PID) of whichever process leads the group.
The practical purpose is signal management. When you press Ctrl+C in a terminal, the operating system sends an interrupt signal not just to one process but to every process in the foreground process group. This lets you stop a pipeline of connected commands with a single keystroke rather than hunting down each one individually. Process groups also determine which set of processes gets full read and write access to the terminal they’re running in. The foreground process group can interact with the terminal directly, while background process groups cannot.
If you launched a shell command that pipes output through several programs (like filtering a log file through multiple tools), all of those programs typically belong to the same process group, so they can be managed as a unit.