Amanda WilliamsProject Manager II| CHG HealthcareDeerfield Beach, Fl, United States
Hello All,
I know it's important to understand the flow of the processes, and know what needs to be done first, second, third, etc.. However, I'm still really confused about the actual flow of the processes. Do you follow them vertically by Process Group (Ie: In "Initiating" you need to Develop the Project Charter first and Identify Stakeholders second and that's it) or do you follow horizontally by Knowledge Area (Ie: In "Integration" you're supposed to Develop the Project Charter first, Develop the PM Plan second, Direct & Manage Project work third, Manage Project knowledge fourth, etc.)??
If it's the latter, then I really don't get it - why are we talking about Identifying Stakeholders in Chapter 13 wayyyyy at the end of the book, when that is something we should be doing at the beginning of the project?
Please help. Thank you, as always! Saving Changes...
In a cascade project form, you may follow processes according Process Groups. This is, first do Initiating, then Planning, Executing, Monitoring and Control and finally, Closing Process Group. But in reality, many processes may be iterative. Monitoring and Controlling is an example of a process that can be repeated along the different phases of the project, to watch project state at different times. In other cases, on hybrid projects, planning and executing activities may be done various times along the project life cycle, to adapt to changing needs. In addition, various processes of the ten areas of knowledge may not be necessary for your specific project, so you must analyze them, and tailor your project management approach according to your industry or activity. Saving Changes...
Dave VioletteRetired| Duke Energy CorporationMooresville, Nc, United States
Amanda
Please do not get caught up in the trap where people think the Process Groups outlined in the 6th Edition of the PMBOK(R) Guide are linear and represent some form of life cycle flow. The Process Groups are exactly what they say they are: a logical grouping of project management processes to achieve specific project objectives. They were never intended to represent a life cycle (I know, probably wasn't a good idea to settle on names such as Initiating, Planning, etc but that happened back in 1996 when the Process Groups were identified).
Process Groups are simply a grouping of processes aimed at attaining a specific objectives. Hence, all of the initiating processes are focused on things associated with initiating a project or project phases. These processes are carried out within a project's life cycle whenever they are needed. The same applies to all of the other processes within the process groups.
It is those who insist on placing a linear view of the processes that get into trouble by thinking a given process does not apply because I am at a different place within a project's life cycle. A given process applies whenever it logically applies (i.e., what questions or actions are you attempting to accomplish).
This simple linear view of the PMBOK(R) Guide is also why many view the PMBOK as a waterfall approach. It is not and never has been.
When it comes to what needs to be done first, simply look at the Inputs and outputs. If a given process requires a prescribed set of Inputs, where did these inputs come from? Simply, look at the Outputs of other processes to see which processes deliver those Outputs to serve as Inputs to the process you are reviewing.
As Veronica has already pointed out, processes may be applied multiple times throughout a project. Essentially they are applied when you need to deliver or update the outputs of that process.
Unfortunately processes do not flow cleanly within one knowledge area or one process group.
As Dave indicates, trace key outputs to get a better understanding of the flow. For example, let's take deliverables.
Direct and Manage Work (Integration/Executing) produces deliverables. Those are inputs into Control Quality (Quality/Monitoring & Controlling) which produces verified deliverables. Those are inputs into Validate Scope (Scope/Monitoring & Controlling) which produces accepted deliverables.
This same approach can be used with change requests to understand how those change state from process to process.
There are a few knowledge areas which are a little more linear - risk is a good example of that. The risk register is like a snowball rolling down a hill. Identify risks gets the initial snowball rolling and the subsequent processes will update your risk register. But always remember even if things appear to be linear, iteration is always possible - for example, when plan risk responses, we could generate secondary risks which force us back through identify, qualitative and quantitative analysis again.
Kiron Saving Changes...
Amanda WilliamsProject Manager II| CHG HealthcareDeerfield Beach, Fl, United States
Thank you, All! That makes much more sense! The way the PMBOK is set up is so odd and makes it seem like you're supposed to be following a specific flow of process. These answers make much more sense. I appreciate the help!
...
1 reply by Kiron Bondale
May 08, 2020 10:40 AM
Kiron Bondale
...
Amanda -
You have to remember that the PMBOK Guide is NOT written as an exam self-study book hence the flow and organization of content will not directly help those studying for the exam.
Good luck with your continued preparation for the exam!
Thank you, All! That makes much more sense! The way the PMBOK is set up is so odd and makes it seem like you're supposed to be following a specific flow of process. These answers make much more sense. I appreciate the help!
Amanda -
You have to remember that the PMBOK Guide is NOT written as an exam self-study book hence the flow and organization of content will not directly help those studying for the exam.
Good luck with your continued preparation for the exam!
Kiron Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Dave and Kiron explained it well, and Veronica mentioned rightly that most processes might be iteratively. Indeed, in each process it is mentioned when they can occur. There are only a few direct dependencies of processes (like scheduling can only be done after sequencing has been done, but then, again, changing schedule goes thru these processes again, and again ..).
PMBoK is a guide, not a step by step approach (which would be a methodology like Prince2). For example, I often start stakeholder identification before developing the charter. Or procurement planning. You as PM have to decide which processes and artifacts to use and when.
The PMP exam questions may be a bit more stringent though.
Thomas makes a good point: just because a process expects an input doesn't mean you can't start the process before you have that input. It just means you will likely work on the process until you receive that input.
Don't think of the various processes as finish-to-start dependencies, they are more like finish-to-finish dependencies. (Planning is very much like that: you work on a lot of different pieces in parallel and they all come together at about the same time.) Saving Changes...
