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
- Scope Planning: plan on how the scope will be defined [plus other activities]
- Scope Definition: a detailed project scope statement as a basis for future [scope related] project decisions.
- 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]
- Scope Verification: formalizing acceptance of the completed project deliverables
- 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).
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”.
, PMBOK 3rd edition, 2004
Photo credit: David Reece @ Flickr
7 thoughts on “Why PMBOK fails to embrace change”
Separation again. I wonder why…
Separate heavy change control process must be there for other reasons than optimal workflow…
How about anxiety management of the management and/or investor?
PMBOK says nothing wrong as such. It is just that it does not give the correct guidance on how to do change management in an efficient way.
Because of this I have seen too many times that there is a separate Change Request process. It is then required to be used to change the project scope agreed in the “beginning”.
In practice, the “traditional” software projects are typically half way into their schedule (or more) before the requirements are signed and “frozen”. Implementation has been going for months before this.
This is actually good. It would be a disaster if coding was allowed to start only after requirements were frozen.
It makes me frustrated that this type of projects have practically no change management before requirements are approved and it is far too complex and stiff afterwards. How could we help these people to see the light? Seems the only solution they can think of is getting the requirements right earlier and on higher level the next time. And they always fail.
You are right. Ultimately the drive to separate (or be analytical as I mention) destroys the value of the practices that PMBOK is trying to support.
If Change management would be part of every day work (in Scrum it is), then it would stop being a problem because the whole process would be built around change!
By separating Change Management as PMBOK suggests, the consequence (not the intention, mind you) is that people assign different people to “manage change” (in bigger projects) and then a new stiff and hard to change process is created with the goal to “reduce” change instead of embracing it!
I agree. PMBOK is not wrong as such, but so was the case with many other software development methodologies, not wrong, just completely destructive in practice.
PMBOK has good intentions, but it creates more problems than it solves in a software development environment.
Scope Planning: Epics, Release Planning
Scope Definition: Product Vision, Epics
WBS: Stories and Backlog (completely consistent with the concept of Progressive Elaboration as defined in PMBoK.
Scope Verification: Sprint Review
Scope Control: Product Backlog meetings
Come on guys. Just because the process is listed separately for discussion in no way indicates it should be broken out from the organization. Just because Scope planning is listed first in no way implies that you have to develop the entire scope before you start any work. Look up Progressive Elaboration and Incremental Delivery in the PMBoK.
If I come in to do an audit on your project, one of the questions I am going to ask is “How do you and the people who pay for your development project stay in synch when there is a major change in the direction of the product?”
You will answer something like – “we have a bunch of epics defined for the product. When a really cool new feature comes up the Product Owner does a power point describing the epic. We add it to our back log. When we get ready to put approach development of an Epic, we have a meeting where we break it down into some stories and we put them into a Sprint. At the end of the Sprint we talk about we finished and get feedback from the Product Owner. Sometimes we do something we call a Spike to prove out a technology or an Architecture and based on what we learn we may go back and change what we thought was possible from a cost or timing standpoint.” You have a method of Scope Management that is entirely consistent with the PMBoK and with Agile.
It is uncommon to have a situation where no expectation regarding features, cost, and timing has been established with customers and people who pay for our work. When what we are going to deliver is going to be different (better or worse) than that expectation we need to be responsible in communicating that to our customers and the people who pay for our work.
The fact that we can present an entirely responsible, standards based method of delivering software that also helps dramatically improve cost, quality, and speed is a good thing.
PMBoK 3rd Edition was published in 2004 – around the same time Ken Schwaber published his book on Scrum. A new release (4th Edition) of PMBoK was published Dec 31, 2008. Just as in software development, the understanding of the body of knowledge has expanded in the last five or six years. Please get a copy of 4th Edition for your discussion.
Another important idea, and this is where a lot of value can be added in this discussion, PMBoK lists types of implementation, but it is a process framework – not an implementation guide. Communicating how typical implementations of PMBoK processes can be destructive to value – and how Agile implementations of these processes can increase value – is more useful to the community than saying “We don’t do Scope and Change management on Agile projects.” That doesn’t sound responsible and it isn’t accurate. “We have integrated practices that make our scope and change management processes more responsive and eliminated a lot of waste that comes from organizational separation of duties and wasteful over-planning” is a valuable message.
I’ll try to get myself the 2008 version of PMBOK.
Note, however, that my point is that in Scrum (specifically, but also in other agile methods) we DO change management, but we do it as part of the daily work (more on this tomorrow in this blog).
In your first comment you say that a PMI-based audit could “approve” an Agile project. Sure, I believe you. An agile project can also pass CMMI audits, but that does not CMMI better for software.
Again, don’t get me wrong. I think there is good stuff in the PMBOK, but it should not be used as a basis for developing processes. Just as RUP should not be used as a basis for creating software development processes (boy, do I have stories about that).
It is very important, in my opinion, that we in the PM and Agile community have an important dialogue about the shortcomings and failures of the PMBOK approach to project management. That’s what I’m trying to do with this series of posts.
BTW, I agree that I can make my message more clear. That’s also why I want to write these posts and get feedback from people like you! Thanks for the help and contribution.
Comments are closed.