Process groups rationale and general principles

The five project management process groups (Figure 3.1) are:

Initiating.
Planning.
Executing.
Monitoring and controlling.
Closing.

Figure 3.1. (a) The five project process groups and their deliverables

Project management process groups are shown in numbered boxes, one to five. The deliverables from each process group are shown after each box, and these are also inputs to the next process group. Note that this is a simplified or idealized representation of the processes and their interaction, but this idealized representation is the best way to learn about the project management processes as they apply in real life, because if this simplified view is understood, then it is easy to understand the complexities and variances that apply in real-life project management processes. Most of the complexities arise in how process groups interact, for example a requested change (output from the Executing process group) is addressed in the next process group (Monitoring and Controlling) but may trigger updating the project management plan, that is, replanning, which involves processes from a previous process group (Planning). This is no more than common sense requires. So why have process groups in sequence if they interact and sometimes work in parallel, or parts of them work in parallel? The answer is that, first, it is logical and efficient to group the main different kinds of processes together, for example so that all planning processes are together, because at whatever stage in the project we do it, planning is planning, and we don't do a fundamentally different kind of planning at different times in the project. Secondly, it helps us to remember why we are doing some particular activity, to determine whether it is essential in our project or essential right now, and to ensure that where there are different ways of using the same piece of information we use it in all ways necessary for our project in short, it is a good way to organize the complexities of project management. (a) Basic outline

Figure 3.1. (b) Some of the major interconnections between process groups and other assets

The general principle behind the process groups is nothing more than the common sense idea of plan, then act. This is a simple but critically important principle so important in project management that it is worth spelling out the obvious: if you start doing things without planning them, chaos followed by failure is the likely result. The complication in project management is that there is in practice a tension between doing more planning and getting on with the doing part. The risk if you get the balance wrong one way is paralysis by analysis, the risk the other way is headless chicken syndrome, that is, much activity to little intended effect. The project management process groups of the PMBOK, and their equivalents in other approaches to project management, have evolved as best practice implementations and development of this simple principle in project management.

There are a number of specialized enhancements on the basic plan-then-do concept, several of them highly valuable. Many organizations have their own preference for one of these, and many teach their preferred model as part of their management development training. If you already have your own variant of the basic plan-then-do model, it is worth understanding that the fundamental principles are exactly the same as those of the project management process groups. This will save you much effort in trying to remember something completely different (it isn't) and also save you the effort of trying to resolve differences in approach (there are no major ones, none that are not fairly easily reconciled); and perhaps most of all if you are new to an organization, it will save you from wasting effort in arguing that the project management process groups should replace whatever is already in place, or, much harder, trying to replace in the PMBOK or some other methodology the process groups with your own organization's version of plan-then-do. You can of course do any of these things, but our advice is to understand the principles and not worry about differences in particular versions, although each version in widespread use is very valuable for the purposes for which it was designed.

We will look briefly at two different versions of the basic plan-then-do principle, both of which are in widespread use in large organizations. They are the OODA loop and the Plan Do Check Act cycle.

The OODA loop

The OODA loop was developed by John Boyd^[1], and is a cycle of four stages:

Observe.
Orient.
Decide.
Act.

The loop and how it works are described in Figure 3.2. A notable feature of the OODA loop is that it splits the Plan half of the simple two-step plan-then-do model into three parts. Planning itself is the Decide part of the OODA cycle. This is preceded by Observe and Orient. The point of this division is to defer planning until one understands enough about the context of the plan. This is, in a way, treating the Plan step as the then-do half of the simple plan-then-do, in other words it is introducing, in a sense, the idea of having a plan for a plan. It is, however, more than this, and shows a more practical grasp of how real life works. It does take time in a new environment or circumstance to soak in the environment and to adjust one's mind to it.

Figure 3.2. The OODA loop

In the case of setting up a substantial new project, the distinction between Observe and Orient is a useful and highly practical one, even if one runs both in parallel to an extent. Observing is about understanding the environment and the wider context in which the project is to sit. The Orient step is about thinking through how the project fits in that context. The difference is that Observe does not involve any consideration of the specifics of the project, whereas Orient does.

These distinctions in the early stages of the OODA loop are most useful when you are setting up a new kind of project in a large and complex organization. They are least useful if your project follows a well-established lifecycle model and is of a kind that you, the project team and the organization have done frequently before (unless there have been problems of customer satisfaction or quality, in which case a close examination perhaps using the OODA tool may be useful this time round). For example, a project to reengineer processes in an organization that has not done reengineering before, or in a division which has not changed its working methods for many years, will benefit more from an OODA-type approach than a project to implement a standard piece of technology with a project team that has done the same thing many times before, working to a project lifecycle that is very much tried and tested.

So if you are in a situation where the OODA loop might be useful, how do you use it in project management? It is simply a case of bearing the principles of OODA in mind as you move through the project management process groups. For example, in the initiating process group, remind yourself that there is a strong Observe and Orient requirement. This could mean using a draft or strawman version of the project charter and the draft scope specification as communication tools to help you Observe and Orient that is, circulating them more widely and engaging potential stakeholders in discussions about them more than would be the case on a project where you did not need the benefits of the OODA loop.

The final observation to make on the OODA loop is that it is a loop or cycle: it continues around.

The Plan Do Check Act cycle

The Plan Do Check Act (PDCA) cycle (Figure 3.3) was popularized by Deming^[2], and comprises the following steps:

Plan to change something.
Do. Test the planned change empirically.
Check. Assess the results of the test, to decide whether to implement change, or make further studies.
Act on the basis of the test and assessment. If this does not produce the desired results, repeat the cycle, with a different plan.

Figure 3.3. The Plan Do Check Act loop

This is similar to the OODA loop, but (a) is more mechanical and less analytical, and (b) places more emphasis on inspecting and correcting after the event than on getting things right first time. However, in practice both OODA and Plan Do Check Act are doing essentially the same thing, and which to use is a matter of taste. The Plan Do Check Act cycle is attributed to W. Edwards Deming, who popularized it, but was originally formulated by Walter A. Shewhart of Bell Laboratories. The cycle is also known as the Deming Cycle, Shewhart Cycle, or Deming Wheel.

Note that the Do step is not simply going out and doing it, but rather together with the Check stage is a test of the plan. Like the OODA loop described above, the PDCA cycle emphasizes planning and preparation, although with the emphasis placed slightly differently.

How to use the process groups

The wrong way to use the process groups in real-life project management is to try to apply them all. Even worrying about remembering them all and how they fit together is inadvisable, we feel. With experience, you will gradually develop a memory for them in real-life project management, to the extent that you need them in your particular work. The right way to use them is to skim through them, and pick out elements of them that look useful to you. Most projects process quite well without the preliminary scope statement, for example, so don't start using it and its associated processes if you don't need it. However, if you can feel in your waters, to coin a phrase, that there is scope trouble ahead right from the start of the project, then consider using it and regard the associated processes as ideas for you to develop. (Of course, if you are taking the PMI exams, you will need to learn the process groups in detail, and if you are new to project management that will be useful.) In a nutshell, if you already have some experience of doing project management, then:

Don't try to use all parts of the process groups.
Don't worry about whether you understand the detail of the process groups and how they fit together you already know most of what you need to know and there are easier ways to cope with any gaps.
Do use the high-level idea of the process groups as a mental checklist to ensure that you are doing the right thing at the right time.
Do use the detail process groups as a guide, to refresh your thinking, or when you hit particular problems.

Those four rules are sufficient advice on how to treat the process groups, but we can say more by way of explanation. The great risk in setting out the process groups as they are set out is the risk of overcomplicating a simple idea. Why then do we set them out like this? There is a general problem with trying to write a guide to project management or to document it, which is that the nature of the subject inherently has this risk. In practice the choice is merely one of which form of potential overcomplication one picks. We have picked the PMBOK as being one of the least risky formalizations, and, being the most commonly used one in the world, we hope that there will be a larger community to ensure that the representation of the process groups is not allowed to harm projects in practice.

The risk is summarized by Max Wideman:

... a well-run project is simply not run like that [i.e. as per the PMBOK model of process groups]. If a project life span is properly configured for ... management control, and the proper levels of conceptualization, definition and planning are done ... then the process group interactions as presented are an unnecessary complication. All that is necessary is to exercise the standard management cycle of plan, organize, execute, monitor and control ...

From www.maxwideman.com/musings/process1.htm

Just to be clear, for practical purposes we recommend reading the process groups in this chapter and understanding the broad principles in them, but not trying to learn all the detail by heart. Pick and choose what you think will be useful, based on your experience of project management in your industry, and refer back to this chapter for further information if you need it. On the other hand, if you are preparing for the PMI exams, you will need to learn some of this by heart. In either case, if you get confused, remember that all the process groups are doing is expanding the basic common sense idea of plan and then act to projects.

Top of Page