This blog post is part of a chapter from an e-book that we are working on at this time. The e-book is a simulation of how to apply a project management method (CAM2P™) on large and complex project integrating a project life span with the PMBOK® Guide. The focus of this part (of the chapter) is to discusses an alternative approach to the PMBOK® Guide planning processes, which we use in the sample project.
Introduction
Project planning is a challenging topic for many reasons. Consequently, it is important to understand this chapter and concepts before one can move into the sample project.
- Some practitioners think planning is a phase[1], yet planning is more about repeated processes rather than a once-off time-bound phase.
- Other practitioners think there is only one plan per project; however, there should be at least one plan for every phase or stage since the planning processes do repeat with every stage.
The earlier chapter addressed these points, however, there is one more area of potential confusion.
Is there one plan, the ‘… … plan’ per phase, or more?
If we are not mistaken, the first version of the PMBOK® Guide considered two plans, a project management plan and a project plan. In later versions, the two plans merged. The current fifth edition of the PMBOK® Guide has one ‘project management plan’, which is for the project or phase[2]. This project management plan include subsidiary plans in each knowledge area[3].
One or Two Plans?
If one considers the PMBOK® Guide planning processes[4] and truly understand them, one will notice that there are two types of planning processes, two sub-groups.
Sub-Group 1
There are processes (one in each knowledge area) that focuses on the management of the knowledge area. For example “Plan Scope Management[5]” (The Project Management Institute, 2013) is about how to collect requirements, how to develop the scope statement, how to create the work breakdown structure, how to validate scope, and how to control scope. In other words, the planning process address ‘how to’ do the other processes within the same knowledge area[6].
The same applies for all knowledge areas. Consequently, there are ten management planning processes; out of the twenty four in the planning process group.
Sub-Group 2
Each of the other fourteen planning processes is about ‘doing’ and producing an ‘output’.
For example, staying with scope management, ‘doing’ the “Collect Requirements” process is about performing analysis, talking with stakeholders, and collecting all of the requirements for the phase, or the project, then documenting these requirements.
Next, consider “Define Scope” process; ‘doing’ the process is to develop the scope statement. The same applies to all of the other knowledge areas and planning processes.
The Two Sub-Groups
Bringing in the concepts of the two sub-groups together, let’s consider the risk management area.
The “Plan Risk Management” process is about ‘how to’ identify, analyze, respond, and monitor and control risks on the project, or phase. Therefore, this process is a management planning process from Sub-Group 1.
Next, there are four risk management processes that are part of Sub-Group 2 and these are the ones for identifying, analyzing[7], and responding to risks. Zooming in on the “Identify Risks” process it is about ‘doing’ the work to identify all potential risks on the phase, or the project. The same is true for the other processes, they are about ‘doing’ the work of those processes.
In summary, and due to the above situation, the CAM2P™ approach is to split the PMBOK® Guide planning processes into management and detailed planning processes, as explained next (In a future post.)
[1] http://blog.sukad.com/20140107/why-planning-is-not-a-project-phase/
[2] There are also “Project Documents” that related to planning (The Project Management Institute, 2013).
[3] There are ten knowledge areas in the fifth edition of the PMBOK® Guide.
[4] There are 24 planning processes (out of a total of 47) per the PMBOK® Guide, fifth edition.
[5] All the names of the processes that are used here are per the PMBOK® Guide fifth edition, copyright and all rights reserved to PMI (The Project Management Institute, 2013).
[6] ‘How to’ may include who, when, what … if applicable.
[7] There are two processes related to analyzing risks, one is qualitative analysis and the second is quantitative analysis.
This
comment was posted on LinkedIn PMLink – Project
Management Link – Project, Program & Portfolio Managers, PMP, PMBOK, PMO
group by Adriana
Bekteshi,
https://www.linkedin.com/groupItem?view=&gid=59531&item=5966095926928891908&type=member&commentID=discussion%3A5966095926928891908%3Agroup%3A59531&trk=hb_ntf_COMMENTED_ON_GROUP_DISCUSSION_YOU_CREATED#commentID_discussion%3A5966095926928891908%3Agroup%3A59531
As for my experience as Project Manager as well
as a person who has studied deeply the PMBOK 5 edition, I consider planing as a
way of thinking. Planing by itself never end, it is a process overall project
and its proper activities. Even during closure of the project we still find
planning elements. The principals of PMBOK are the guide to lead how should be
planned, or better to say how should think a project manager during planning (
project implementation). Project Manager never stop thinking planning acting
doing and still again the same process. The project is like the real life, we
always think before doing, we always have a plan and a backup plan for our
everyday action. Basically the process of planning should be documented and
respected in order to have an effective and efficient project. The PMBOK still
here come in help with creating the Project Management Plan, which in itself
have its sub plans. To conclude my opinion is that Planing is the whole one
process which is expressed or materialized on different sub plans and documents
that associate them.
This
comment was posted on LinkedIn PMLink – Project
Management Link – Project, Program & Portfolio Managers, PMP, PMBOK, PMO
group by Robin
Vysma,
https://www.linkedin.com/groupItemview=&gid=59531&item=5966095926928891908&type=member&commentID=discussion%3A5966095926928891908%3Agroup%3A59531&trk=hb_ntf_COMMENTED_ON_GROUP_DISCUSSION_YOU_CREATED#commentID_discussion%3A5966095926928891908%3Agroup%3A59531
The problem with prescriptive detailed models
is that they don’t always apply. What you do in the planning stages of a
project will depend on exactly what you are planning. It’s going to be unique
to your project. Your efforts will generally increase in momentum and formality
in an iterative cycle of ideas->details->endorsement culminating in the
development of a project execution plan (charter?). The boss’s response ‘how
much will that cost?’ is authorisation to your spending some time gathering
data. At next week’s staff meeting the response might be, ‘OK write it up as a
proposal’. Mass generalisations coming from statistical analysis of past
projects can give some insites into project culture and human behavior but it
won’t tell you what to do next because a project by definition comes without
the convenient precedent upon which traditional management is based.