Many posts often boil down to PMI is Waterfall, Agile is not, and for complex projects agility (and the focus on empirical measurement) is the clear winner.
That sentence alone should be enough to trigger apoplectic rage in some corners followed by yet another flamewar.
The history of the PMBoK is heavily weighted by the lessons learned from the engineering sector of North America. So from this background is it any doubt that there will be a strong focus on the tools and techniques of the PM; since the PMP is expected to learn the PMBoK, then PMPs are de facto immersed into a world of defined Processes.
The PMBoK is broken down into 5 Project Management Process Groups:
- Monitoring & Control
and 9 Knowledge Areas:
- Human Resources
(I use “I saw two crows quietly having coffee and reading poetry” to recall this.)
This creates a 5×9 matrix into which 42 project management processes are scattered, and just to make it more difficult the distribution is uneven. Some cells are empty (for example, there are no processes in the Project Scope area Initiation Group, but the Project Time cell for the Planning Process has 5 process.
So, looking at one of these process – for example, in Section 4.3, Direct and Manage Project Execution – the PMBoK states that this process is used to “Direct and Manage Project Execution is the process of performing the work defined in the project management plan to achieve the project’s objectives.” It then goes on to detail example activities and the role of the PM.
The PMBoK then goes on to illustrate the “inputs, tools and techniques, and outputs” with this figure:
Next, we get the “Direct and Manage Project Execution Data Flow Diagram”:
So just to recap; the PMBoK has 42 processes, and your PMP has to know every single one of them and how they fit together.
The benefit is that when a group of PMPs, or PMs who are familiar with the PMBoK, get together they all speak the same language; they have their own common tongue.
The downside of this is that it can become a modern day Shibboleth and meetings descend into technobabble. The other temptation is that, with such an extensive list of processes, it is far too tempting to disengage the brain and just turn it all into a massive workflow with a checklist of fixed steps and key deliverables.
However, this does the PMBoK a disservice; at no point does the PMI or PMBoK Guide dictate methodology.
That said, the first edition came out in the mid-90’s and, as the Waterfall had been the dominant model for so long even in software, is it any surprise that the PMs simply took what was there and mapped it onto their own world and what they ‘knew’ worked? So step by step many software PMs either consciously or unconsciously associated the PMBoK and Waterfall.
One good side of this was a number of practitioners got so frustrated with seeing more and more software developers being forced down a route that they saw failing, that Agile started to take root. The 90’s saw a number of different Agile approaches scrapping it out while the Waterfall gorilla just got bigger and heavier.
Eventually, a few processes (Scrum, XP, Lean, etc., the ones we know well today) started to prove out and so, fast forward to a Utah ski resort in February 2001, and the birth of the Agile Manifesto – and the rest is history.
So, can a PMBoK PM become Agile? Well, Jeff Sutherland (Co-inventor of Scrum) and Nafis Ahmad (PMP & Certified Scrum Master) seem to think so: See How a Traditional Project Manager Transforms to Scrum. Just need to start by thinking what the PMBoK is looking to achieve and not just blindly follow the steps.