If you are just getting started in project management, want to brush up on your skills, or plan to take a project management certification exam, you'll need to understand project management process groups.
A "process group" is simply a fancy name for a stage or step in the lifecycle of a project. The "stages" in the process groups process model are:
The five process groups comprise a project management model that is used to organize a complex project from start to finish. The reason why the stages or steps are called "process groups" is that each stage encompasses a variety of sub-steps or processes.
This language of process groups is specific to a certain project management philosophy from an organization called PMI.
PMI stands for the Project Management Institute. It is the premiere certifying body for project managers worldwide. One of its most well-known certifications is PMP, or Project Management Professional. PMI sets standards for project managers known as the Guide to the Project Management Body of Knowledge or PMBOK®.
Therefore, if you read or hear about PMI process groups, PMP process groups, or PMBOK process groups, they are really all the same thing: process groups as defined by PMI, the Project Management Institute.
PMI is by far the most recognized and popular certification body for project managers in the world, but most especially the United States. However, it is not the only game in town (or on the planet).
In the United Kingdom, PRINCE2 is the recognized credential of the UK government. Other project management certifying bodies around the world include IPMA, APM, and AIPM.
PRINCE2 has its own process model, which is similar to PMI's process groups, but adds two main processes for a total of seven. "Planning" is considered to be integral to all stages of the project. The stages are as follows:
Other project management organizations may have their own models or ways of organizing processes. AIPM, for example, is focused on an "Agile Inclusive Process Model."
A common area of confusion among people studying the PMBOK Guide to obtain a project management professional certification is the difference between PMI process groups and knowledge areas.
Process groups are stages in a project lifecycle. It is a way to group tasks to keep a project organized and focused on the end goal. Process groups are general and can be applied to any number of different projects.
Knowledge areas are similar tasks or activities that relate to common knowledge or skill sets. A group of similar tasks can become a knowledge area.
Note (and this is important!): Knowledge areas can be spread across different process groups (or stages) of the project lifecycle.
"Project Cost Management" is an example of a knowledge area where the specific tasks such as cost estimation and managing costs can occur in different parts of the process.
Once you have a basic understanding of what process groups are (simply stages in a project), the actual process groups aren't that difficult to understand. They flow in logical order from the start of a project to its finish.
The process group "Initiating" simply refers to everything that you might do to launch a project and get it started. This might include determining the basic project goals, identifying project team members, and solidifying the project budget.
At this stage of the project, initial permits and work orders need to be in place. If starting a project with a client, a signed agreement with an initial down payment might be in order. A high level of scope and requirements will be determined at this stage in the project, but more fully fleshed out in the next stage: Planning.
Documentation you might use at this stage: work orders, permits, agreements, RFPs/tenders, project charter, stakeholder register.
The process group "Planning" is exactly what the name suggests: planning. This is the time to fully plan the project, including setting any milestones or project outcomes. Scope, requirements, and deliverables will all be more clearly defined and parsed out.
Planning isn't something to skimp on. It should be thorough. For this reason, the PMBOKÂ® Guide articulates 24 individual processes that can comprise the Planning process group.
Documentation you might use at this stage: scope/deliverables document, project management plan, schedules, risk register.
The "Executing" process group is where the rubber meets the road and the project is implemented. At this stage in the game, multiple individuals and/or teams may be working on separate components of the project at the same time (see "knowledge areas" above).
Documentation you might use at this stage: project updates.
During the course of the entire project, the project manager will be monitoring everything to make sure that milestones are met, and deliverables are produced on time.
The project manager is also keeping a close eye on project scope to ensure it doesn't veer too wildly off track. If it does, the project manager will ensure that the new scope is clearly defined, and the budget and timeframe updated accordingly.
Documentation you might use at this stage: change of scope requests, updated schedules.
The "Closing" process group is all about successfully shutting the project down when it is completed. While it may be tempting to keep the project in a state of limbo, where it is not officially closed, this is not the best idea.
Especially if you are working with clients, a final close should be agreed to with the project, lest the customer be tempted to come back for unlimited (and free) updates.
Documentation you might use at this stage: client sign-off of completed project.
Here is an example of how a PMP's process groups can help with a simple project. We'll use the example of a website build and launch. We'll call the company building the website "Interactive Company" and the client "Online Shopping Mall." Here is how the process groups might work:
Initiating: Online Shopping Mall agrees to hire Interactive Company to build their new ecommerce website. They sign an agreement with a basic budget, scope, and project timeline. Interactive Company identifies the staff they want to work on the project: A project manager, two programmers, a graphic designer, and a creative director.
Planning: Interactive Company's project manager determines reasonable milestones for deliverables to be shown to the client along the way. For example, a mock-up of the website design should be completed by the graphic designer in three weeks. Meanwhile, the programming team will work on developing a custom back-end, with a prototype due in 5 weeks.
Executing: The programming team gets to work on the e-commerce setup while the creative director and graphic designer work on brand collateral and a design mock-up.
Monitoring and Controlling: During the entire project, the project manager makes sure the design and technical teams are doing their jobs. The project manager is also coordinating with the client to make sure that expectations are kept in check. If the client starts to ask for things beyond the initial scope, such as adding app development to the project, the project manager makes sure this is clearly defined, scheduled, and paid for.
Closing: The Online Shopping Mall website has been launched and works perfectly. The client is now asked to sign off on the completed project, with a clear delineation that any new updates to the website are part of a new project.
Whether you are a PMP certified project manager or never plan to pursue an official certificate, process groups can be a helpful project model. They provide a framework for looking at and defining projects that can help keep them on track. While understanding the basics is fairly simple, as you learn more about project management, you'll find a lot more "under the hood" to master. Good luck!
Yad is not just the leader of the Project Management Training Institute (PMTI). He helped to write significant portions of the project management standards worldwide. He is helping PMI right now in reviewing, directing, and leading the development of the 7th edition of the PMBOK® Guide to incorporate the most monumental changes to project management standards in 35 years. He shares his wisdom with readers via the PMTI blog.