One of the biggest changes in PMBOK® version 6 is that it has incorporated more guidance about Agile. Does PMBOK version 6 go far enough to integrate Agile?
- I think that the release of PMBOK version 6 and The Agile Practice Guide is a huge step forward. It is a noble attempt to create a more integrated approach for integrating Agile and traditional plan-driven project management;
- However, the full integration of Agile and traditional project management requires some very major shifts in thinking. It even involves something as fundamental as adopting a much broader definition of what “project management” is.
This is a step in the right direction but I don’t think that simply adding some words about Agile to PMBOK is going to be sufficient to bring about the kind of shift in thinking that is needed.
What is “Project Management?
The crux of the problem is that for many years the essence of what “project management” is has been centered on some very well-established stereotypes of what “project management is. Those stereotypes are based on achieving predictability and repeatability as shown below:
Traditional Project Management Emphasis
That’s the primary way people have thought about what “project management” is since the 1950’s and 1960’s. A successful project manager is one who could plan and manage a project to meet budgeted cost and schedule goals. That obviously requires an emphasis on planning and control.
The way to achieve predictability and repeatability has been to have a detailed and well-though-out plan and then control any changes to that plan.
Many people loosely refer to this approach as “Waterfall” because, in many cases, it has been implemented by using a sequential phase-gate process. However, I don’t believe that description is entirely accurate:
- I prefer to refer to it in more general terms as “traditional, plan-driven project management”
- PMI has started using the term “predictive” to describe this kind of project management approach because the emphasis is on predictability
What’s Wrong With That Definition?
In the 1950’s and 1960’s that approach worked well and it was particularly in high demand for large, complex defense programs that were well-noted for cost and schedule overruns. At that time, the primary goal was to achieve predictability. In fact, that approach has been so prevalent that it has essentially defined what “project management” is. Since that time, many project managers don’t see any other way to do project management.
The problem with that approach is it only works well in environments that have a fairly low level of uncertainty where it is possible to develop a fairly detailed plan prior to the start of the project.
Factors Driving Change
In today’s world, there are several major factors driving change:
- The environment we live in today has a much higher level of uncertainty associated with it. That makes it very difficult, if not impossible, to develop detailed plans prior to the start of a project
- Solutions are more complex and are much more difficult to design and optimize
- Competitive pressures demand high levels of creativity and innovation in spite of the level of uncertainty in the environment. Producing high-value business results is more important than predictability in many cases.
The New Environment
This new environment demands a very different kind of project model that looks more like this:
Think of a typical new product today like the next generation of the iPhone. Do you think that a traditional plan-driven approach with an emphasis on predictability, planning, and control would work well to develop that kind of product?
How Are PMBOK and Agile Different?
The differences in how these two approaches have been defined and implemented in actual practice are very significant:
| Area | Traditional Plan-driven Approach (PMBOK) | Agile Approach |
|---|---|---|
| Process Control Model | Based on what is called a “Defined Process Control Model” | Based on what is called an “Empirical Process Control Model” |
| PM Emphasis | The emphasis of is on planning and control to achieve predictability over project costs and schedules | The emphasis is on using an adaptive approach to maximize business results in an uncertain environment |
| PM Role | Project management functions are typically implemented by someone with clearly-defined responsibility for that role called a “Project Manager” | The functions that might normally be performed by a “Project Manager” at the team level have typically been distributed among other roles |
| Implementation | Following a well-defined plan and process are typically important | Reliant on the judgement, intelligence, and skill of the people doing the project to fit an adaptive approach to the nature of the project |
Is the Agile approach shown above in the right-hand column not “project management? A lot of people would not recognize it as “project management” because it doesn’t fit with many of the well-defined stereotypes of what “project management” is. I contend that it is just a different kind of “project management” that will cause us to broaden our thinking about what “project management” is.
“Project Management” should not be limited to a particular methodology. A project manager should be capable of delivering results using whatever methodology is most appropriate to achieve those results.
Is One Approach Better Than the Other?
There are a lot of Agile enthusiasts out there who will advocate that Agile is a better approach for almost any problem you might have.
My opinion is that saying “Agile is better than Waterfall” is like saying “A car is better than a boat” – they both have advantages and disadvantages depending on the environment that you’re in.
- An Agile approach works best in situations that have a relatively high level of uncertainty. In those situations, creativity and innovation to find an appropriate solution are more important than predictability. For example, if you were to try to find a cure for cancer, it would be ridiculous to try to develop a detailed plan for that effort.
- A traditional plan-driven approach works well in situations that have a relatively low level of uncertainty and where predictability, planning, and control is important. For example, if you were building a bridge across a river, it would be equally ridiculous to say: “We’ll build the first span of the bridge, see how that comes out , and then we’ll decide how to build the remaining spans.”
Are These Two Approaches Mutually-Exclusive?
A lot of people have the mistaken belief that there is a binary and mutually-exclusive choice between “Agile” and “Waterfall”:
- There has been a lot of polarization between the Agile and project management communities for a long time. Many people in these two communities have seen these two approaches in conflict with each other
- PMI has treated these two areas as separate and independent domains of knowledge for a long time with little or no integration between the two
It takes a higher level of skill and sophistication to see these two approaches in a fresh new perspective as complementary to each other rather than competitive. It is a challenge to learn how to blend them together in the right proportions to fit any given situation but it definitely can be done.
Does PMBOK version 6 go far enough to integrate Agile?
I have ordered a final copy of PMBOK Version 6 and haven’t actually seen it yet; however, I have seen early preview editions and I think I understand where it is trying to go. I have several concerns:
- As I’ve mentioned, I think that there is a huge and fundamental shift in thinking that is needed to rethink what “project management” is. I’m not sure that simply adding some words about Agile to PMBOK is going to be enough to help people make that shift in thinking. It requires seeing “project management” in a fundamentally and radically different perspective.
- The whole concept of PMBOK does not seem to be very consistent with an Agile approach:
- Agile is based on some very simple and succinct principles and values. It relies very heavily on the training and skill of the people performing the process to interpret those principles and values in the context of a project
- The latest version of PMBOK is over 700 pages long. It’s supposed to be a “guide” but it seems to try to provide a detailed checklist of things to consider for almost any conceivable project management situation.
Putting those two things together is like trying to mix oil and vinegar. They just don’t blend together very well and attempting to blend the two approaches at that level doesn’t seem to make much sense.
What is the Solution?
This is definitely a challenging problem. Agile and traditional plan-driven project management are like two different religions – they both have a common goal of delivering business results but the way each approach goes about doing it is very different.
There are two significant components of the solution to this problem:
Developing an Integrated View of Project Management
Somehow, we have to create a much more unified view of what “project management” is. That view should fully embrace Agile as well as traditional plan-driven project management. However, modifying PMBOK to totally integrate Agile would be very difficult. Its like setting out to create a unified view of religion. A better approach might be to cross-reference the two sources to identify areas of similarity and then create an over-arching guide to blend the two approaches together to create a unified view of religion.
I believe that is essentially what PMI has attempted to do with The Agile Practice Guide. I discussed that in a separate article. For a long time, PMI has treated Agile and traditional plan-driven project management as separate and independent domains of knowledge with little or no integration between the two. The new Agile Practice Guide attempts to bridge that gap and show a more integrated approach to those two areas. I think that is the only reasonable strategy that makes sense for now.
Develop a New Breed of Agile Project Managers
This “raises the bar” significantly for the whole project management profession. In my Agile Project Management books, I have often used the analogy of a project manager as a “cook” versus a project manager as a “chef” that was originally developed by Bob Wysocki:
- A good “cook” may have the ability to create some very good meals, but those dishes may be limited to a repertoire of standard dishes, and his/her knowledge of how to prepare those meals may be primarily based on following some predefined recipes out of a cookbook
- A “chef,” on the other hand, typically has a far greater ability to prepare a much broader range of more sophisticated dishes using much more exotic ingredients in some cases. His/her knowledge of how to prepare those meals is not limited to predefined recipes, and in many cases, a chef will create entirely new and innovative recipes for a given situation. The best chefs are not limited to a single cuisine and are capable of combining dishes from entirely different kinds of cuisine
Related Articles
Check out the following related articles on “Agile and PMI”:
- What’s the Impact of an Agile Project Management Approach?
- What’s New with PMI-ACP and How Does It Impact My Training?
- Reinventing Project Management
- What’s Different About PMBOK Version 7?
- PMI Acquisition of Digital Agile Delivery (DAD)
- What is the Purpose of the New PMI Agile Practice Guide?
- PMBOK and Agile – Does PMBOK Version 6 Go Far Enough to Integrate Agile?
- Is PMP Certification Still Relevant in Today’s World?
- Will PMBOK Ever Be Compatible With Agile?
Additional Resources
Resources for Agile Project Management Online Training.