Planning Process Group of PMBOK

The Planning Process Group, among the 5 Process groups, has the most number of processes, as defined in the PMBOK Guide (Sixth Edition).

It also has a particular sequence in which these processes must be done, which helps the most in planning for a project. This is because each process has an impact on another process, and in the whole planning process. This proper sequence is not listed in the PMBOK Guide. The guide merely lists all the process, required in each knowledge area.

But in real life projects, you don’t do things in the order of the knowledge areas as listed in the PMBOK Guide.

Rather, you do things depending on the stage of the project – more like process groups – You do planning once the project has been mooted, and kick started. Then once all the planning is done, you move to Executing the project.

Among the 20+ processes just within the Planning Process Group, which one are you supposed to do first? Is there a sequence to it? Yes, there is… but you won’t find it in the PMBOK Guide.

Defining who is going to do what, and in what sequence, while doing planning is extremely important.

For example, do you plan for the cost first, or the quality first, or plan out a schedule first. What about outsourcing, contracting, procuring things from outside of the company? When should that be planned. When do you estimate resources, when do you think about risk etc.

You see, you need a way to structure things within planning…

Structure of Planning

Some things naturally go before others, and it is quite obvious… yet, we have seen countless projects where the order is mixed up, and you get a poor project management plan. With a poor quality of planning, the execution is bad too… and everyone suffers.

Get the structure of planning correct, and your project management plan will be so much better!

First things first. Can you plan the time or cost if you don’t understand the scope of the work correctly and completely?

I’m sure you answered – No.

So the first thing is to understand how to go about planning and managing the project scope completely. Thus, you should first plan to “plan out how the scope will be collected, understood, defined completely”.

In the PMBOK Guide, under Scope Management Knowledge Area, the first process is “Plan Scope Management Plan“. This is where you come up with a plan of how to define, clarify, build and manage the scope. It acts as a guide when you or anyone has questions regarding the scope of the project.

Keep in mind, we are NOT defining the scope of the project at this time, but defining and crystallizing our plan of how to go about managing Scope of the project, so that there are no surprises later on, and everyone knows what to do, and why we are doing it. This plan should be so good that it shouldn’t have to get changed often. It should be able to handle changes to the scope of the project, define the process to get exceptions approved, handle scope creep, and handle change requests to the scope appropriately and completely.

Who will do this work of planning “The Overall Project Management Plan”?

Well, we need to assemble a core team, an smaller, initial team of people who will do this planning, and help to define the requirements by talking/interviewing the customers. This is usually done in Acquire the Project Team process, outlined under Human Resource Management.

Once we have a good Scope Management Plan, we can then execute it to come up with the detailed scope of the project. The Scope Management process of Collect Requirements, with its 11 tools & techniques will assist to grab the raw requirements of the project from our customers and key stakeholders.

We can then Define the Scope after going through a few rounds of “what should be done, and what should be excluded“, based on time, budget, and other constraints. Then we can show the final scope to the customer, and get them to agree on the detailed scope statement of what would be actually delivered in the project.

Once the project & product scope is finalized, we can then begin the process of breaking down this project scope into Phases, Sub-Projects, and smaller Work Packages. We keep on doing this until we have broken each higher level work to the lowest level, where it can be done in about a week, or less. This makes each work package small enough to be correctly estimated, and later, managed and controlled, during execution. This breakdown of work is done in the Create WBS process of Scope Management knowledge area.

Now we see the entire scope baseline clearly. We now must break the required work into smaller activities, sequence them and come up with a high or medium level Network Diagram. Not too detailed yet… but enough to begin estimating the people required. This is done in Time Management Knowledge area.

We should now begin to get an idea of what kind of people are going to be needed for this project, how many people may be needed, and whether they will be found internally, within the organization, or externally.

If they can be found within the organization, you will then have to talk to them or their managers to facilitate their availability to the project when the time comes to do their part.

If you are going to outsource some of the work, you can begin to work on the Procurement Management Planning, and developing smaller Procurement Statement of Work, so you can give it out to the potentials sellers, in their preparation for the bids. You can get some indicative timeline and costing for the outsourced work.

Then begins the task of looking at the entire scope, the availability, experience, suitability of the people to do the work, and begin the task of estimating how long it would take to do the work, The project team assists in estimating the resources required, the estimated time required to do each work package, each activity, and develop time and cost estimates. The cost associated for each work – based on the people required, plus any equipment and material needed for the activity is estimated.

Once time and cost estimates are established for each activity and work package in the entire WBS, we should have a detailed breakdown of the schedule, costs and resource requirements. Adding and rolling them up to a higher level can begin to give you the overall timeline, and overall cost requirements. We can then look at the Critical Path of the Project.

Based on available time, money, resources, and priorities of deliverables, some sections can be moved around within the WBS and Network diagram. Once everyone on the project team is happy with the end result, we can then begin to share this plan with the customer and get their buy in too. This concludes with the schedule being base-lined in the Develop Schedule process.

You don’t have to share your internal costs and resources so much with the end customer… in case you are worried about the customer seeing your allocated resources or the planned costs. Just share the timeline in the WBS and Network Diagram is good enough. It also shows them how seriously you are taking the project, and how you are working at the smallest level of detail, diligently. Nothing should be missed out.

With a customer’s nod, the Schedule can be base-lined. Internally, the costs can be nailed down too. Of course you’ve got to think about the Contingency Reserve, and how much funds are required for the day to day emergencies, for things popping up on the fly, for which the project manager will have to spend some time and money.

You and your management will also have to work out a Management Reserve, the amount that is kept for the unknown unknowns – new things that have not been thought of that might change the course of the project. Keep some amount for this… Your management, even when they have complete faith on you and your abilities to get the project done on time and on budget, will usually keep some money aside for unexpected things cropping up.

Don’t rejoice yet. We have only looked at the Scope of the project, Time required to do it, and the Estimated Cost of the project based on the scope, time & resources. There are several other areas, like Quality, Communication & Risk, which have to be factored in now.

Quality on the project does not happen automatically. You can not leave it to the individual team members to deliver the quality they feel like. Quality on a project begins by understanding the requirements & the quality required by the customer, and then taking the time and money to deliver that quality.

First identify the quality requirements, the processes required to deliver that quality, how will quality be measured, what quality metrics and standards are to be followed, how will quality be audited (QA), how will quality be controlled (QC: Control Quality process) on the project.

With a clear idea about quality standards, metrics, QA & QC requirements, we have to then look at the additional resources required to do it. If existing people are doing the work, you need to buffer in the required time for making sure that QA & QC are performed. Most project managers only look at the time required to do the work, without including the time for a Good Quality job – which would include quality audit & quality control time. You may need to have a separate Quality Control team, as the people doing the work will often be blind-sided – biased that their work is of high quality and does not require any testing.

If you added any activities, work packages, or increased the time or money for any activity as a result of assessing and planning for quality, it would now alter your cost and time estimated done earlier, and make them better, bringing your planning a notch higher.

Even the best laid plans get haywire. There’s many a slip between the cup and the lip. Good project managers stay alert and expect the unexpected. This requires us to Plan for Risk (any event that can happen in the life of the project, which may impact our project time, cost or any other dimension).

A Risk Management Plan should be created, which would guide you and the team on how to plan, analyze, manage and control risks, much before their happen. The biggest benefit is that it brings focus to the things that can go wrong… this is an area that most people do not want to think about… because of the fear of being labeled as “negative thinkers”. But it is timely to bring the cat out of the bag.

It should be healthy and proactive to talk about risk, and plan for it before hand. PMI recommends you to start a Risk Register – a document that outlines each risk, its probability of happening, and its impact, if it happens. This can then help to qualify the risk as High, Medium or Low (Qualitative Risk Analysis process), and a numeric score can be attached (Quantitative Risk Analysis process).

Finally, you can then proactively work out a Risk Response Strategy – what should be done if the risk happens… what would be our strategy. Do we want to come up with an alternative plan, probably change the course of action, come up with a mitigation plan (a plan to reduce the probability or the impact of the risk), and contingency plan (in case the risk still happens).

Planning for Quality & Risk can be very enlightening. It can introduce new work packages, add cost and alter the baselines considerably.

For example, if you notice that your team members are new or inexperienced, it can be a risk that your project may not be able to deliver on time, or on the required quality. To overcome this, you might want to send the team for training, to learn the correct way of doing things beforehand. This requires time off from the project, and will cost you more. Plus, what’s the guarantee that after you’ve sent them for training, they will not make mistakes. They may make less mistakes, but it can still happen. You might then decide to put some of these resources under a mentor or supervisor, to oversee the work more closely. This further deepens your time, cost, and resource requirements.

As you can see, doing Quality Control, Monitoring for Risk, Sending people for training etc. can have a huge impact on your project. Yet, it make take more time and money to do them.

Since the benefit may not be apparent right now, but the extra cost and time requirements are more evident, there is a tendency to reduce or cut the time & money spent on Testing, Quality Control, Risk Mitigation etc. This is a potential pitfall for real projects, and often the biggest cause of failure.

Another area you need to look into now is the Communication with key stakeholders, customers, team members, functional managers, PMO, management to name a few. The time to communicate is often not factored at all in projects. It is assumed that communication happens automatically, and that not much time is required to do it.

Most projects need a dedicated Communication Team, who would collate raw data, analyze it, and convert it into information. Individual work packages are being completed, delays are happening, and different people need information about the project right now. Some may need summary information, some may need detail. Some need it daily, while others need it weekly or monthly. Some can be sent by email, or dropped in share drives, while others may need to be communicated in meetings, presentations.

It takes time to prepare and present the right information to the right person, in the right format, and in the right frequency. Failure to do so creates a feeling of distrust with the project and its manager.

This time and effort to Communicate has to be updated in the overall project plan and the schedule and cost baselines need to be revised too.

Further, there are some iterative activities, which need time and effort. Things like Conducting a Risk Re-assessment, Developing and Conducting a Process Improvement activity, which will look at how things are being done, and look for ways to improve them right now, before it gets too late. There is a continuous focus on Preventive activities, Proactive actions and reduce reactive, costly defect repairs. The frequency, people, time, resources, money to do these activities need to be planned in advance.

Planning also requires you to plan the Execution of the project. How to begin the execution, how to manage the execution of the project, and how to Monitor & Control the project. Even how to Close each project phase and then finally, close the entire project must be planned out.

Some of this over-arching planning – for the different process groups is done as part of Integration Management Knowledge Area, where plans for each phase are developed. However, since planning a project well is half done, coming up with a complete, holistic project management plan, which consists of individual plans to manage scope, time, cost, quality, communication, human resources, risk, procurement and stakeholders is paramount for project success.

As you have seen, the scope and schedule baselines were amended several times, to update the impact created by quality management, risk management, communication management, human resource management, procurement management, and stakeholder management.

There has to be several iterations of all of these, before we can derive the complete project plan, where the impact of activities done in one process has been handled in other processes.

Once the entire project plan is completed, it should be presented to the Key Stakeholders, Customers for review, and sign-off. If people do not agree on the plan itself from the very beginning, it will be difficult to get their buy-in when you begin to execute the project.

After receiving sign-off, the project execution can be kicked-off, and you should celebrate the signing-off of the project plan, and the beginning of execution with a big bang!

Wow! That’s how big and impactful Planning processes are. No wonder that 24 of the 47 processes in the PMBOK Guide, Fifth edition, belong to Planning process group. That’s more than 50%.

Mastering these will give you good scores in the PMP exam, and give you enough clarity on what to do and expect when doing actual projects.

So, in essence, you can look at the key processes, in some order as:

Plan how you will do the planning.
Finalize Requirements.
Develop Project Scope Statement
Determine Team
Create WBS & WBS Dictionary
Create Activity List
Create Network Diagram
Estimate Resources
Develop time and cost estimate
Determine Critical Path
Develop Schedule
Develop Budget
Determine quality Requirements, processes, metrics, standards
Develop Process Improvement Plan
Determine Roles and Responsibilities
Develop Communication Plan
Risk Assessments
Iterations to go back and review all the other plans, as they impact each other
Plan What to Purchase
Prepare Procurement Documents
Finalize how to execute, monitor & Control
Develop final PM Plan, performance measurement baselines that are realistic
Gain Formal Approval of Management / Sponsor
Hold Kick-off meeting

1 thought on “Planning Process Group of PMBOK”

  1. Kindly can you clarify to me why : “Plan What to Purchase
    Prepare Procurement Documents” comes after iterations ? while in rita book she state that it come after scope statement.


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Warning: count(): Parameter must be an array or an object that implements Countable in /home/pmchamp/public_html/wp-content/plugins/slickquiz/php/slickquiz-front.php on line 59