The Five Process Groups

In project management generally - and the Project Management Body of Knowledge (PMBOK® Guide) specifically - best practices dictate a very specific series of process groups that should be performed. These are referred to as Initiating, Planning, Executing, Monitoring and Controlling, and Closing. The question arises: what problem are we trying to solve by having five discrete process groups? (In the PMBOK Guide, they are called process groups because each one contains or houses specific processes that should be performed). The answer is that these processes give us an organizational background to successfully plan, execute, and manage a well-run project. With that said, let's look at each of these process groups in turn and discover why each is so vital to a project's success.

Initiating

According to PMI, the process of Initiating helps to set the vision of what is to be accomplished. This is where the project is formally authorized by the sponsor, initial scope defined, and stakeholders identified. Stakeholder identification is crucial here because correct identification (and subsequent management and control) of stakeholders can literally make or break the project. This process group is performed so that projects and programs are not only sanctioned by a sponsoring entity, but also so that projects are aligned with the strategic objectives of the organization. Where this is not performed, projects may be started and carried out haphazardly, with no real stated goal or objective.

It should also be noted that management chooses and authorizes the project manager here. It's crucial to authorize and establish the PM early as project managers often have accountability but little authority. Strictly speaking, if you don't formally authorize a project, you don't have a project.

Key documents created: Project Charter and Stakeholder Register.

Planning

A crucial element of planning is establishing the total scope of the project. While it may appear as though that was accomplished in Initiating, scope (along with risks, milestones, summary and budget) was defined there at a high level. Here, through an iterative and more detailed planning process, called progressive elaboration, project documents are developed at a much more detailed level.

In the PMBOK Guide, PMI defines twenty-four discrete processes that are involved in planning. While a project team can decide which of those to choose for a given project, the message is clear: fail to plan, plan to fail. Too many organizations start a project with only a cursory amount of planning assuming that - one supposes - everything will fall into place. But too often, without any real or sufficient planning, chaos prevails.

Below is the official PMBOK's Process Groups which list each of the various processes. Note the below Table is from PMBOK Guide 5th Edition. The latest is the 6th edition which was released in 2017 and has 49 processes. (The 5th Edition had 47 processes)

PMBOK Processes and Process Groups (5th Edition)

A significant concept in Planning is that the team is able to think the whole project through in advance. So they not only create a variety of plans but also consider all the things that might go wrong (risks) and how they might respond to them. (For the record, the team should also look for unforeseen things that might benefit them - called opportunities - that they can exploit). What types of plans get created? First and foremost, a project management plan, a document that guides execution of the project. This is essential in that it becomes an overriding governance document for the entire project.

Without going into detail on every single document created, a short list would include:

Documents that bound scope (what we are and are not doing);
Documents that list detailed requirements;
Documents that provide estimates for cost and time;
Documents that provide for a schedule;
Documents that plan for quality, communications, risk and procurement.

Further we create baselines for scope, schedule and cost against which we can then (in Monitoring and Controlling) track our progress. And we continue to plan for how we will manage and engage the all-important stakeholders throughout the project life cycle.

A cursory glance at the above will reveal the basic nature of what is accomplished during Planning. It creates your roadmap, your path to success. You should no more fail to prepare these plans than an architect would fail to create a blueprint for a building. At the end of this process group, the team should have a very good idea of not only what they're tasked to do - what is in and out of scope - but also what it will take to execute the project on-time and on-budget.

Key documents created: Project Management Plan, schedule, risk register

Executing

Naturally, the next thing to do after Planning is to execute, to do the work. But what's important here is that we now have a project management plan to which we can execute. It helps keep us on track. Here is where the project team starts doing the work of creating the deliverables while the project manager coordinates those resources. And if that were the only thing that occurred, that might be enough. But there are several other things that must happen during executing.

Since the project team is so important to successful execution, one must assume that developing the team is important to that cause. So there is an assumption that the project manager will not only acquire and manage the team, but also cultivate it by performing team-building exercises. Likewise, the PM is not only managing communications but also managing the stakeholder engagement, ensuring project and product quality and - if procurement is involved - supporting the effort to contract with a vendor.

It is in this area of Executing that most of the budget will be spent and the deliverables of the project will be produced. And it is likely here where we will begin to see stakeholder change requests. While the project team can implement approved changes, only the change control board can approve or reject these changes.

Project execution could go on for days, weeks, months or years depending on its duration. But it is not enough to execute only. One must make sure the project stays on track. That is where our next process group comes into play.

Key documents created: None. Updates only.

Monitoring and Controlling

While the other process groups occur sequentially, Monitoring and Controlling hover over the whole project and so, happen throughout the project and are not linear. What does it encompass? According to PMBOK GUIDE, these are "processes required to track, review and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes.1" The truth is, you can't assume you'll always stay on plan. In fact, it's likely as not that you won't. Monitoring and Controlling is where you get back on track, where you compare plan to actual, measure variance and take corrective action.

Some examples of areas one might control are scope, cost, and schedule. These all have variations in regards to which tools and techniques you would use to control them. But what each of these have in common is that they have baselines which were defined in planning. Since we're tracking our progress against these baselines, you don't make changes to them lightly. They can be made. But as mentioned, only the change control board can approve these changes.

One way to think about monitoring and controlling is to imagine that you were driving across the country according to your plan or a roadmap. But if you got lost and you didn't have a GPS you'd stop, ask for directions and get back on track, or maybe based on new information, such as a new road that would cut hours off the trip, you'd change or update your plan.

The lesson learned here is that assuming that you'll somehow magically stay on track just because you've planned to be is a recipe for failure. Only constant vigilance, tracking and reporting will keep the project focused towards meeting its objectives.

Key documents created: None. Updates only.

Closing

From its name, it should be pretty obvious what happens here. Not only do you formally close the project but you also get sign-off and acceptance from the customer. While this should be self-evident, too often projects just fizzle out. People stop coming to the meetings and everyone just shows up at the next one. Best practice dictates that the rigor applied to the rest of the project should be applied here as well. The project manager should formally close the project by archiving records, holding a lessons learned session, making final payments, closing contracts and celebrating and releasing the team. And the lessons learned along with other historical information should be centrally archived to be used as input to future projects to prevent reinventing the wheel.

The bottom line is that while these process groups are not necessarily easy to implement, not doing so means the team may never realize the full benefits of their highly strategic projects.

Footnotes

1. A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition, p.57 Project Management Institute ^

Search This Blog

Identity and Access Management, Identity Governance