Why PMBOK fails to embrace change

Yesterday we talked about the Project Management Plan process and how it is not adjusted to many software organizations. Today we will talk about the Project Scope Management knowledge area in the PMBOK.

PMBOK defines that within this Knowledge Area there are five processes[1]

1. Scope Planning: plan on how the scope will be defined [plus other activities]
   
2. Scope Definition: a detailed project scope statement as a basis for future [scope related] project decisions.
   
3. Create Work-Breakdown-Structure: dividing [large] project deliverables and project work into smaller, more manageable components [but this particular component is also used for "cost accounting" of the project]
   
4. Scope Verification: formalizing acceptance of the completed project deliverables
   
5. Scope Control: controlling [unwanted] changes to the project scope
   

NOTE: the []'s above are my own additions.

According to PMBOK each of these 5 processes has at least 8 activities and some up to 19 separate activities (Scope Control specifically)[1].

Having so many separately defined, yet inter-dependent activities in a book like the PMBOK points to a key failure in much of the PMI focus. In the drive to standardize the project management process (PMBOK is ANSI standard 99-001-2004) the description of the activities is exhaustive and detailed. It is analytical. In Agile, many of the major breakthroughs have been in not being analytical, but rather synthesizing knowledge into practices. Take the example of Scope Control, one of the processes in the Project Scope Management knowledge area.

According to PMBOK:

Project scope control is concerned with influencing the factors that create project scope changes and controlling the impact of those changes. (...) Project scope control is also used to manage the actual changes when they occur and is integrated with the other control processes. Uncontrolled changes are often referred to as project scope creep. Change is inevitable, thereby mandating some type of change control process.

As you can understand from the quote above there's an emphasis on activities related to change control (you have to love their choice of words), because "change is inevitable".

In Agile project management approaches we try to avoid having explicitly separating change control by incorporating it into the core process being used to develop software. This is a HUGE (I'd like to use even bigger letters) difference between what PMBOK and Agile are about.

In Agile we really take seriously the fact that "change is inevitable", and that's why we don't build an extra process for change management. Why? Because often these change control processes are the very reason why projects fail. See for example government fixed-price & fixed-scope projects.

The counter-intuitive insight here is that by isolating change control as a separate process we make change management stiff and slow, rendering it an obstacle rather than an enabler to success.

Now, it still is useful to talk explicitly about how we intend to manage change. That is useful, but ultimately not enough.

If I was advising a new project manager, I certainly would ask them to read about change management in projects. Not just from PMBOK, but also from other books like Mary Poppendieck's Implementing Lean Software Development or any of the many Agile Project management books for example.

On the other hand, I would never, ever suggest that we should have a separate change management process in a software project, and that is, for all intents and purposes what the PMBOK suggests by taking it's heavily analytical approach.

Again we see that PMBOK is indeed useful, but certainly not enough!

In the next post I'll look at some specific ways in which Agile processes explicitly take into account change management without creating an extra process but rather building change management into the everyday activities: synthesizing one of the most important processes into "how we run the day-to-day activities in projects".

[1], PMBOK 3rd edition, 2004

Photo credit: David Reece @ Flickr