The planning process group

What is the planning process group?

'To fail to plan is to plan to fail.' We take it that the idea of planning needs no explanation. The planning process group is the set of processes used in project management to create a plan by which to manage the project. A vital element of the plan is the scope, and it is so critical in project management that it merits being listed as a separate output of the planning process to the overall plan (see the PMBOK definition), although it is a section of the plan. There are risks both of doing too much planning, and of doing too little. There are a number of complications in all but the smallest and simplest projects and one of the main aims of the planning process group is to deal with these complications.

PMI says

Planning processes

'Planning Processes (Process Groups). Those processes performed to define and mature the project scope, develop the project management plan, and identify and schedule the project activities that occur within a project.' PMBOK Guide (p.367)

The particular complications facing a project or a phase of a project in planning will depend on the particular project and especially on the particular team and organization involved. Note too that planning, unlike the previous process, initiating, is one that continues throughout the project. Whereas initiation should in a well-run project have a definite end point, in a well-run project of any size planning is something that continues almost to the very end, as new factors arise and existing factors change or their ramifications to the project become better understood: there is a constant need for replanning. The complications in planning include:

• How often to replan?

• How to manage information needed as inputs to planning when some of the information is constantly being updated?

• How to manage a variety of levels of quality and reliability of inputs to planning?

• How to determine the level of granularity and accuracy at which to plan? And how far ahead?

• How to control changes to the plan?

• How to control the impact on execution of the plan of intended but not yet approved changes to the plan?

• How to manage and communicate planning options so that they can be discussed effectively without the communication process sending the wrong signals?

• How to minimize the bureaucracy of planning?

• How and when to involve stakeholders in planning?

As a rule, if your project faces any of these questions, it is more important to decide on an answer to the question and stick to it until you make a definite decision to change it than to worry about getting the perfect answer 'you' here meaning the sponsor and the project manager jointly. Try to be pragmatic, make a decision, see if it works, and if not change it. For example, take the first question, how often to replan? Suppose that you don't really know, which is quite likely. Gut feel may suggest to replan every two months, with a major replan every six months. Unless anyone can say definitely why that is a bad idea, give an alternative replanning schedule and convince the project manager and sponsor that it really is better, stick with it, and don't spend too much time in discussion. Then, if it becomes clear that more frequent replanning is necessary, change. Equally, if the replanning burden at two-monthly intervals is outweighing the benefits, then change and reduce to replanning every three or four or maybe even six months.

Table 3.2 summarizes the results of the planning process.

Table 3.2. What planning is, in terms of before and after planning

Before planning	After planning
No plan exists in sufficient detail to use to manage and control execution.	A plan exists that is usable for executing the project.
The scope is defined loosely and incompletely, in the Preliminary Scope Statement.	The scope of the project is well understood together with the ramifications for the project and the performing organization and key stakeholders, and all these are documented in the scope statement (included as a section within the project plan).
The project manager does not have an intuitive feel for proceeding confidently in the next (say) 3 months.	The project manager feels confident intuitively that they know what should be happening in the next 3 months.
The stakeholders are not confident in the plan.	All stakeholders have been engaged, understand the plan as it affects them or may (through project risks) affect them, and have their own copy of the plan or part of it.

What is the output of planning?

The main output of the planning process group is of course the project plan, and, important not to forget, updates to the plan. One of the main reasons that projects go wrong is that actual activity diverges from the plan because the plan is not updated to reflect necessary or desired changes. This would not matter if the plan had no value in other words, if there is any point in having a plan, which there is, then the whole point is to have a plan that guides execution, and if you allow the execution of project work to proceed unplanned then you might as well not bother with a plan. A complication here is the risk that the project may come to feel as if it is about producing the plan instead of producing the final product of the project. This risk needs to be managed, by having a plan that is the right size, neither too small nor too big, and the right structure for the project, the organization and the project team. Throwing away the plan is not managing this risk, it is increasing it; and failing to update the plan to the point where the plan is not showing what is actually happening and what is intended to happen in the project is in effect the same as throwing away the plan. The planning processes, if you select just the ones relevant to your needs, will help you to manage this risk efficiently.

The PMBOK Guide gives a full list of inputs and outputs for the planning processes, and it should be studied carefully by anyone doing the PMI's exams, and is likely to be valuable to any practising project manager.

Who should be involved in planning?

Who should be involved depends entirely on the kind of project. Very small projects can be planned fully in one's head, written on a postcard, and executed from memory. Large projects, to build a large tunnel or to launch a new bank or to create a major new retail service, may need teams of people on individual elements of the plan.

Top of Page