What Does PMBOK v6 Mean For the Future of Project Management?

Background

PMBOK version 6 and the new PMI Agile Practice Guide signal a new direction for project management that, for the first time, starts to integrate Agile and traditional plan-driven project management. What does that mean for the future of project management?

I’ve written a number of articles on the future of project management and I still get a lot of questions from project managers who are confused about the impact of Agile on project management and ask questions like “What Agile certification should I get?”. Unfortunately, it’s not as simple as just going out and getting another certification like PMI-ACP and suddenly you are an Agile Project Manager.  The PMI-ACP certification is a step in the right direction and it’s not an easy certification to get but it’s just a test of general Lean and Agile knowledge and is not aligned with a particular role. In fact, the role of an Agile Project Manager Is not well-defined and there is even some controversy among some people that there is a role for an Project Manager In an Agile environment.

Confusion Over Project Management Direction

It’s totally understandable why there would be a lot of confusion among project managers as to how Agile and the future of project management impact their career direction.

  • There are some project managers who are in “denial” and want to assume that traditional, plan-driven project management is the only way to do project management, will go on forever unchanged, and Agile isn’t really a valid form of project management at all.
  • On the other hand, there are people in the Agile community who believe that there is no need at all for traditional plan-driven project management at all and Agile is a solution to almost any problem you might have

I’m not an Agile zealot – I try to take a very objective and pragmatic approach. In one of my courses I have a slide that says “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. You have to be able to fit the approach to the problem rather than force-fitting all problems to one of those extremes. I am convinced that project managers who only know how to do traditional, plan-driven project management and try to force-fit all projects to that approach will be at a severe disadvantage relative to other project managers who know how to blend Agile and traditional project management in the right proportions to fit the situation.

What’s Wrong with Traditional, Plan-driven Project Management?

There’s nothing inherently wrong with the traditional, plan-driven approach to project management; the problem is in how its applied. The primary problem with the traditional, plan-driven approach is that it works for situations where the requirements are well-defined and the primary concern is planning and managing a project to meet those well-defined requirements within a given budgeted cost and schedule. That approach just doesn’t work well in situations where the requirements are much more uncertain and the primary concern is not just managing costs and schedules but taking an adaptive approach to maximize the business results and value that the project produces.  In today’s rapidly-changing business environment the need for taking that kind of approach is becoming increasingly common.

The Future of Project Management

There’s essentially two sides of this equation: value and cost – in the past, with most traditional plan-driven projects, the value side has been assumed to be well-defined and fixed and project managers only needed to worry  about the cost side.  In this new environment, that is no longer true – project managers now need to worry about both maximizing value as well as managing costs and schedules.  That’s a fundamental shift in thinking for many project managers – it means:

  • Taking a broader focus on maximizing the business value that a project produces and using whatever methodology (or combination of methodologies) that makes sense to achieve those goals
  • Fitting the project management approach to the nature of the business problem rather than force-fitting all projects to a standard, plan-driven approach.

That raises the bar significantly for many project managers.

What Certification Should I Get?

Some people seem to think that it is only a matter of getting another certification and I’ve participated in several discussions lately where project managers were asking questions like: “What certification should I get in order to get into Agile (CSM/PSM, CSPO, or ACP)?”  The answer to the question of “what certification should I get” depends on what role you want to play and it requires some thought and planning because there is no well-defined role for a project manager in Agile at the team level.  There are several possible career directions for project managers with regard to Agile.  You may not have to completely throw away your project management skills, but you would have to rethink them considerably in a very different context and you may not use some project management skills very fully at all depending on the role you choose.

  1. Become a ScrumMaster –  A ScrumMaster is what’s known as a “servant leader”. The Scrum Alliance defines the primary responsibilities of a ScrumMaster as follows:
    • Ensures that the team is fully functional and productive
    • Enables close cooperation across all roles and functions
    • Removes barriers
    • Shields the team from external interferences
    • Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint planning
    • Facilitates the daily scrums

    There’s a few project management skills that might be useful (at least indirectly) for that role but it doesn’t utilize much of the planning and management skills that a project manager typically has.  For that reason, becoming a ScrumMaster may or may not make sense as a career direction for many project managers.

  2. Become a Product Owner –  The Scrum Alliance defines the primary responsibilities of a Product Owner as follows:
    • The product owner decides what will be built and in which order
    • Defines the features of the product or desired outcomes of the project
    • Chooses release date and content
    • Ensures profitability (ROI)
    • Prioritizes features/outcomes according to market value
    • Adjusts features/outcomes and priority as needed
    • Accepts or rejects work results
    • Facilitates scrum planning ceremony

    The Product Owner role actually includes a lot of project management functions but it is actually much more similar to a Product Manager than a Project Manager.  The major differences are that:

    • The Product Owner is a business decision-maker and requires some business domain knowledge that a project manager may not have.
    • The Product Owner role doesn’t typically include many team leadership skills. In an Agile environment, team leadership is more a function of the ScrumMaster and the team itself.
  3. Hybrid Agile Project Management Role – For a lot of good reasons, many companies will choose to implement a hybrid Agile approach that blends the right level of traditional plan-driven project management with Agile. This is a very challenging role for a project manager to play because it requires a deep understanding of both Agile and traditional plan-driven project management to know how to blend these two seemingly disparate approaches together in the right proportions to fit a given situation.
  4. Project/Program Management of Large, Complex Enterprise-level Agile Projects – There is a legitimate role for project managers in managing large, complex enterprise-level projects; however, there are several things to consider about planning your career in that direction:
    • This role is limited to large, complex projects that typically require multiple Agile teams and require blending together some level of traditional plan-driven and Agile principles and practices in the right proportions to fit the situation. This role doesn’t exist at all on most small, single-team Agile projects.
    • This role requires some very significant skills that can be very difficult to attain. Many people may assume that the PMI-ACP certification qualifies you to perform this role. It is a step in the right direction, but a lot more experience and knowledge is needed to perform this role including:
        • Knowing how to blend traditional, plan-driven principles and practices in the right proportions to fit a given project,
        • Adapting an agile approach to fit a business environment, and
        • Scaling Agile to an enterprise level.

      You have to be a “rock star” Agile Project Manager to perform this role.

In many industries and application areas, the project management role associated with small, single-team projects may be completely eliminated by Agile. There may be some project managers who are not significantly impacted by this such as project managers in the construction industry, but even in those industries some knowledge of Agile principles and practices may be essential.

This creates difficult choices for a Project Manager to make, but the key message for any project manager should be that Agile will force them to make some significant choices about their career direction and it isn’t as simple as just going out and getting another certification (like ACP).

Agile Project Management Training

That’s exactly the challenge for the future of project management profession that the courses in the Agile Project Management Training I’ve developed are designed to address:

The Future of Project Management

What is the Purpose of the New PMI Agile Practice Guide?

PMI recently published PMBOK version 6 as well as a new document called “The Agile Practice Guide”.   The Agile Practice Guide is a totally new kind of document for PMI and raises some questions about “What is the purpose of the new PMI Agile Practice Guide?”

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.  A major goal of these two new documents is to start to develop a more integrated view of these two areas and I think this is a major step forward to begin to close this gap.

A lot of people may have thought that integrating these two areas might be as simple as adding more content about Agile to PMBOK version 6 and that PMBOK version 6 would become a universal guide to both of these areas.  I don’t believe that to be a realistic way to accomplish that goal at all (See my article on Does PMBOK Version 6 Go Far Enough to Integrate Agile? )  As I mentioned in that article, that would be like trying to get Christians and Muslims to develop a unified view of religion by adding more words about Christianity to the Koran or more words about the Muslim religion to the Bible.  That approach just wouldn’t work.

What is the Purpose of the New PMI Agile Practice Guide?

Agile and traditional plan-driven project management are two radically different approaches to project management that each require significant individual focus; however, at the same time, we need to build a much more unified view of these two areas and I think that is exactly the role that the Agile Practice Guide attempts to fill.  Here’s how I see these various documents fitting together:

What is the Purpose of the New PMI Agile Practice Guide?

Here’s how I see this all fitting together:

  • PMBOK has become well-accepted for many years as the “bible” for a traditional plan-driven approach to project management; and, to some extent, some (not all) of the practices in PMBOK provide a general foundation for a general project management approach
  • Documentation related to Agile takes on a very different format which is based on some very simple and succinct values in the Agile Manifesto as well as other more specific documentation related to Agile practices such as Scrum, Kanban, etc.

Those two formats are very incompatible with each other in my opinion, but there is some commonality and we need to start to developing a more unified view to tie these two different worlds together.  That is the major purpose that the PMI Agile Practice Guide attempts to serve in my opinion.

What Does This Mean for the Future of Project Management?

This strongly reaffirms what I’ve been saying for a long time. The way of the future seems very clear:

  • There is not a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people have seemed to think and those two areas are actually complementary to each other rather than competitive.
  • There is a continuous spectrum of different approaches ranging from to heavily plan-driven (predictive) at one extreme to heavily adaptive (Agile) at the other extreme and the right approach is to fit the methodology to the nature of the problem rather than just force-fitting a problem to some predefined methodology (whatever it might be).
  • The project manager of the future needs to be proficient in both of these approaches and also know how to blend the two approaches as necessary to fit a given situation.  In the not-too-distant future, any project manager who only knows how to do traditional plan-driven project management and attempts to force-fit all projects to that approach will be at a serious disadvantage.

What is My Review of the Agile Practice Guide?

Here’s a brief summary of my review of the Agile Practice Guide:

General Comments:

  • Overall, I think this document is well-written and really helps to close the gap between Agile and traditional plan-driven (aka predictive) project management; however, that is a huge gap and there is still a lot more work to be done to create a truly integrated project management approach.
  • Agile and traditional plan-driven project management are two very different ways of thinking and it will be very difficult to fully integrate the two.  This is a great step in the right direction but it’s not the final step to close that gap.

Specific Comments:

  • Agile PM Role – I don’t think this document has gone far enough to address the real “elephant in the room” of “What exactly is the role of a Project Manager in an Agile environment?”. There are many project managers who are in denial about that and think that their project management role will go on indefinitely unchanged.  There is a need to address this issue more directly so that project managers can plan their future career direction.

In the back section of the document where it talks about the PMBOK Guide knowledge areas, in a number of different places it says that the role and expectations of a project manager don’t change in an Agile environment.  I don’t agree with that at all – the role of a project manager at the team level (if there is one at all) will likely change radically to more of a coaching and facilitation role than a traditional PM role.

  • Organizational Perspective – The authors of The Agile Practice Guide made a decision to limit the scope of this document to project and team-level work and to exclude discussion of the context of implementing Agile at an enterprise and organizational level.  I think that is serious a mistake.

Treating it as a project level function is much too limiting because most Agile implementations cannot be successful without some level of organizational transformation.  Furthermore, the role of a project manager is either non-existent or very limited at the team level and that will force many project managers to move up to more complex enterprise-level projects.

  • Agile Mindset – The section on “Agile Mindset” is really important and probably could be beefed up a lot. There is a big shift in mindset that is needed but it’s not just a matter of a choice between adopting an “Agile Mindset” or a “Traditional Project Management Mindset”.

In many cases, you need to blend the two approaches and take a broader view of what “project management” is that fully embraces both of those approaches.Many people would not view “Agile” as “Project Management” because it doesn’t fit the normal stereotype of what “project management” is; however it’s just a different form or “project management”.  That’s a big mindset change that PM’s need to make – we need to rethink what “project management” is in broader terms that include all forms of project management including Agile.

  • Relationship of Lean and Agile – I don’t agree with the graphic on page 11 showing that Lean totally encompasses Agile.  It does not – there is a lot of overlap between the two; however, taken to an extreme, each would tend to pull you in somewhat different directions.  Both are focused on customer value but lean is more heavily focused on efficiency where Agile is more heavily focused on flexibility and adaptivity.
  • Agile versus Predictive – The document talks about a spectrum of alternatives with predictive at one end point and Agile at the other end point.  The idea of a spectrum of approaches is right on but I don’t think that the use of the word “Agile” for an end point is the right choice.  Agile should not be an end point because there is not just one way to do Agile – there is a range of choices for Agile.  This spectrum should reflect different levels of planning and I think the end-points are “adaptive” and “plan-driven” (or “predictive”).
  • Hybrid Approach – The section on hybrid approaches needs to be improved. This is a critical area for PM’s to understand and, as it is currently written, this is too high level and not specific enough to help a PM understand how to really implement a hybrid approach.
  • Team Roles – I would like to see the discussion of team roles expanded.  One particular subject that is not covered is how many project functions that might normally be performed by a project manager have been assimilated into other roles in an Agile environment.  Agile uses a distributed form of project management.

Overall Summary

If you are a PMI member, you can download a copy of the Agile Practice Guide from the following link:

https://www.pmi.org/pmbok-guide-standards/practice-guides/agile

I am very pleased to see the PMI Agile Practice Guide being published.  It is definitely a step in the right direction and is very consistent with the integrated approach to Agile Project Management that I’ve developed in the Agile Project Management Academy.

This raises the bar significantly for project managers and will require a lot of retraining of project managers and rethinking of what “project management” is in much broader terms.

 

Does PMBOK Version 6 Go Far Enough to Integrate Agile?

PMBOK® version 6 was released recently and one of the big areas of change is that it has incorporates 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 and 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 and it even involves something as fundamental as adopting a much broader definition of what “project management” is.

Does PMBOK version 6 go far enough to integrate Agile?

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 I think 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 that 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 and 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 and 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 and 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.

In today’s world, there are several major factors driving change:

  1. The environment we live in has a much higher level of uncertainty associated with it which makes it very difficult, if not impossible to develop detailed plans prior to the start of a project in many situations
  2. Solutions are more complex and are much more difficult to design and optimize
  3. 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.

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 to project management with an emphasis on predictability, planning, and control would work well to develop that kind of product?

How Are These Two Approaches Different?

The differences in how these two approaches have been defined and implemented in actual practice are very significant:

Traditional Plan-driven Approach Agile
Approach
Process
Control
Model
Based on what is called a “Defined Process Control Model” which means that the process is well-defined and is not expected to change over the course of the project.

It is also repeatable and consistent across similar projects.

Based on what is called an “Empirical Process Control Model“.  The word “empirical” means “based on observation”.

That means an adaptive approach where both the product that is being developed and the process to create that product are continuously modified as necessary based on observation as the project is in progress.

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
Process
Definition
Relies on detailed process guidance such as PMBOK on almost every possible aspect of managing the project Based on some fairly simple and succinct principles and values (Agile Manifesto)
Project
Methodology
Typically uses a well-defined methodology Typically based on Scrum which is really more of a framework than a prescriptive methodology
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 where creativity and innovation to find an appropriate solution are more important than predictability.   For example, if you were to set out to find a cure for cancer, it would be ridiculous to try to develop a detailed upfront 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 and 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 and to learn how to blend the 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:

  1. 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 help people make that shift in thinking to see “project management” in a fundamentally and radically different perspective.
  2. 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 and 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 to me.

What is the Solution?

This is definitely a challenging problem.   It’s sort of like trying to get Christians and Muslims to agree on a unified view of religion.  They both believe in God but they  have very different ways of worshiping that we’re not likely to change.  A similar thing could be said about Agile and traditional plan-driven project management – 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:

  1. Developing an Integrated View of Project Management – Somehow, we have to create a much more unified view of what “project management” is that fully embraces Agile as well as traditional plan-driven project management.  However, modifying PMBOK to totally integrate Agile would be like trying to modify the Koran to totally integrate a view of Christianity into it.  It just wouldn’t work at all.  If you were to set out to create a unified view of religion, that approach would be ridiculous.  A better approach would be to cross-reference the Bible and the Koran 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 which I  discussed 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 areas.  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.
  2. 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

    I think that sums up the transformation that needs to take place – Agile “raises the bar for the project management profession significantly and what we need to develop are more project managers who are “chefs” rather than “cooks”.  PMBOK is based on a “cookbook” approach to project management and attempting to blend an “Agile” cookbook with PMBOK is not going to make it much better.

    This is exactly the challenge that the Agile Project Management training I’ve developed is designed to address.

Is a PMP Certification Still Relevant in Today’s World?

I recently participated in an online discussion where someone asked the question “Is a PMP certification still relevant in today’s world?” I thought is was a good question. I am a PMP myself, I have had a PMP certification since 2004, and I’m proud to be a PMP but I recognize the limitations of a PMP certification.

IS a PMP Certification Still Relevant?

What Are the Limitations of PMP®?

PMP is heavily based on a traditional plan-driven project management approach (what many people loosely call “Waterfall”) and the world is rapidly changing today.  There’s nothing inherently wrong with a traditional plan-driven approach to project management under the right circumstances, but we definitely shouldn’t try to force-fit all projects to that approach.

  • A traditional plan-driven approach to project management works well in situations where there is a relatively low level of uncertainty and predictability is important
  • It does not work well in situations with a high level of uncertainty where creativity and innovation are more important than predictability

In today’s world, a project manager needs to be capable of using a broader range of methodologies (Agile and plan-driven) to fit the nature of the project rather than force-fitting all projects to a traditional plan-driven approach.  Situations are becoming increasingly common that require a more adaptive approach due to rapidly-changing technology and a very dynamic and very competitive business marketplace.

For those reasons, Agile is having a profound effect on the project management profession in many areas that will cause us to rethink the way we do project management.  That doesn’t mean that traditional plan-driven project management and PMP are obsolete but we’ve got to think of project management in broader terms and recognize that traditional plan-driven project management is not the only way to do project management.  Check out this article for more on that:

What is “Agile” and Why Is It Important to Project Managers?

Is PMI-ACP® the Answer?

PMI-ACP is a step in the right direction but it doesn’t go far enough in my opinion.  PMI-ACP is only a general test of Lean and Agile knowledge and it doesn’t really address the big challenge that many project managers face today of “how do I blend Agile and traditional plan-driven project management in the right proportions to fit a given situation?”  Unfortunately, PMI still treats Agile and traditional plan-driven project management as fairly separate and independent domains of knowledge with little or no integration between the two.

What About PMBOK® Version 6?

We all know that the final edition of PMBOK version 6 is due to be released in September 2017 and it is supposed to contain more references to Agile.  I haven’t seen the final version of PMBOK version 6 yet but I can’t imagine that it will solve this problem either.  The whole concept behind PMBOK is not very compatible with an Agile approach.  These are two very different ways of thinking:

PMBOK Agile
PMBOK is based on the idea that you can develop a checklist of things to consider in almost every conceivable project management situation that you can imagine. Agile requires a very different mindset.  An Agile approach needs to be much more adaptive and it would be impossible to develop a checklist defining what to do in every conceivable situation you might find yourself in in an Agile environment.
PMBOK and traditional plan-driven project management are based on a defined process control model Agile is based on an empirical process control model which means that both the product and the process to produce the product are continuously adapted based on observation throughout the project
PMBOK  is over 500 pages long with lots of details on what to do or consider  in various situations Agile is based on some very brief and succinct principles and values without a lot of detail and expects you to figure out what to do in a given situation.
PMBOK  is also based on compartmentalizing a project into distinct and well-defined process groups Agile requires a much more holistic and integrated approach to project management

So What is the Long-term Solution?

This is not an easy problem to solve. In the long-term, the solution to this problem is likely to involve some very significant rethinking of both PMBOK and PMI certifications to create a much more integrated approach for blending Agile and traditional plan-driven project management principles and practices; however, that is a very difficult problem to solve and is not likely to happen for a while.

Some elements of PMBOK and PMP are definitely useful as a foundation for any kind of project management; however, the depth of study and knowledge required for PMP certification tends to “brainwash” people into thinking that is the only way to do project management and that is not the case.  Someone who only wants a foundation of knowledge in traditional plan-driven project management principles probably doesn’t need that depth of knowledge.

What’s probably needed in the long-term is something like a “PMP Lite” that provides a foundation of project management knowledge without the depth of knowledge that is in PMP for someone who wants to ultimately move into an Agile Project Management role. Here’s what this new certification structure might look like:

Is PMP Still Relevant in Today's World?

The full PMP certification (as it exists today) would still be appropriate for any project managers who plan to specialize in traditional plan-driven project management; however, that depth of knowledge in plan-driven project management should not be needed for someone who wants to develop an integrated Agile Project Management approach.

What’s the Short-term Solution?

In the short-term:

  • If you already have a PMP certification today, that knowledge is a good foundation to begin to develop a broader focus on an Agile Project Management approach; however, it does require a lot of rethinking of how to do project management and also requires a very different mindset.
  • If you don’t already have a PMP certification today and are early in your career as a project manager, you have a much more difficult choice to make between two directions:
    1. Getting a PMP – Making a significant investment in time and money to get a PMP certification and then perhaps moving on to learn an Agile approach sometime later.  If you are working in an industry or application area where traditional plan-driven project management is still the dominant way of working, that might be  a reasonable choice.
    2. Skipping PMP – If you’re not working in an industry or application area where traditional plan-driven project management is the dominant way of working, getting a PMP may not make sense.  Certainly, some foundation of traditional plan-driven project management is worthwhile but you may not need a full PMP.  An alternative is to skip getting a PMP and just focus on developing an integrated approach to  Agile Project Management.

In my opinion, skipping PMP and developing a more integrated Agile Project Management approach seems reasonable for anyone who doesn’t already have a PMP and is interested in an Agile Project Management role.  However, it is a very difficult path to follow in the short term  because there is currently no certification built around an integrated approach to Agile Project Management and the knowledge base is not well-developed either.  For that reason, you have to be somewhat of a “pioneer” in choosing this direction and with no certification, “you don’t know what you don’t know”.

What is ‘Agile’ and Why Is It Important to Project Managers?

I think a lot of people are confused about “What is ‘Agile'” and the importance of Agile to project managers.  The word “Agile” has many different connotations and many project managers think that it is something that only applies to software development and doesn’t apply to them at all.

What is ‘Agile’?

What is 'Agile'
“Agile” means a lot of different things to different people:

  • To some people it means just developing software faster,
  • To some people, it means creating a more people-oriented project environment,
  • To others, it means making the project management process a lot more efficient by streamlining the whole process and eliminating unnecessary documentation

Those are only a few different connotations – there are many, many more. There are also many more stereotypes, myths, and misconceptions about what Agile is. All of those things are potential outcomes of an Agile process but that’s not the fundamental essence of what an Agile process is all about in my opinion.  The fundamental essence of an Agile process is adaptivity.

What’s Wrong With the Typical Project Management Approach?

Many project management processes, as we know them today, were designed around what is called a “traditional plan-driven project management” model (what many people loosely call “Waterfall“).  In this model, achieving predictability over the outcome of a project and the costs and schedule associated with achieving that outcome is very important.  Therefore, it is also very important to have clearly defined requirements as well as an adequate level of planning to be able to somewhat accurately predict the outcome, costs, and schedule of the project.

That’s the predominant way that project management has worked since the 1950’s and 1960’s. A project was considered successful if it delivered what the requirements for the project called for within the defined budget and schedule. That kind of predictability can be important – for large investments, it allows a company to:

  • Attempt to calculate with some level of certainty what the return on their investment is likely to be from a project
  • Make a go/no-go decision as to whether the project should be funded or not based on that information.

The primary problem with that approach is that it requires developing a fairly detailed plan for the project upfront and that is very difficult, if not impossible to do in projects with a very high level of uncertainty.

Why Is Adaptivity Important?

We live in a different world today from the world that existed in the 1950’s and 1960’s when formalized project management approaches were first defined.  There is a much higher level of uncertainty:

  • Technology is rapidly changing,
  • Solutions are much more complex, and
  • The business environment that we operate in is dynamic and constantly changing.

In that kind  of environment, if you attempt to develop a detailed plan for a project with a lot of uncertainty upfront, it will typically require you to make a lot of assumptions, many times those assumptions will be wrong,  and that may require significant re-planning and possible rework later.

Rather than force-fitting a project that has a high level of uncertainty to a traditional plan-driven approach, it’s much better to fit the methodology to the nature of the project and that’s where a more adaptive approach really makes sense.  It doesn’t mean that you don’t do any upfront planning; it means that you use a level of planning that is appropriate to the level of uncertainty in the project:

Traditional Plan-driven Approach Adaptive (Agile) Approach
Atempt to develop a detailed set of requirements and a detailed project plan for the project upfront Limit the amount of upfront planning based on the level of uncertainty in the project and use a “rolling-wave” planning approach to further define the requirements and plan for the project as the project is in place

What’s an Example of a Project Requiring an Adaptive Approach?

I use an example in my Agile Project Management training that is a somewhat extreme but it gets the point across. The example I use is:

Suppose you were given the task to find a cure for cancer and you were asked to outline what the solution will be, how long it will take to develop it, and what the total cost of the research will be to develop the solution.

In that situation, it would be ridiculous to attempt to develop a detailed project plan with accurate cost and schedule estimates – there is just way too many uncertainties to resolve. So what would you do? Give up and do nothing? That doesn’t make sense either.

In that situation, we do know some things about finding a cure for cancer based on years of research that have gone into that area but there are still way too many unknowns to develop a detailed project plan for a solution. What you would do is take advantage of what is known as much as possible and then take an iterative, trial-and-error approach to find a solution.

That’s the way Edison invented the light bulb…here’s a quote from Edison on that subject:

“I speak without exaggeration when I say that I have constructed three thousand different theories in connection with the electric light, each one of them reasonable and apparently to be true. Yet only in two cases did my experiments prove the truth of my theory. My chief difficulty, as perhaps you know, was in constructing the carbon filament, the incandescence of which is the source of the light.” (1890 Interview in Harper’s Magazine)

In a 1910 autobiography of Edison, Edison’s friend and associate Walter S. Mallory is quoted as asking “Isn’t it a shame that with the tremendous amount of work you have done you haven’t been able to get any results?”  The book goes on to say that “Edison turned on him like a flash, and with a smile replied: Results! Why, man, I have gotten lots of results! I know several thousand things that won’t work!”

What Makes This Kind of Project Different?

There are two things that make this kind of project fundamentally different:

  1. The level of uncertainty is very high and makes it impractical or impossible to develop a detailed plan for the project upfront
  2. Creativity and innovation required for finding a good solution are far more important than predictability

How Does an Agile Approach Solve This Problem

An Agile process is built on an “Empirical” Process Control model. The word “empirical” means “based on observation”. In the context of an Agile development process, it means that during the course of a project, both the product as well as the process to produce the product are continuously refined as the project is in progress to produce the right product and to optimize the value of the product being produced.

Empirical Process Control Model

Why Is This Important to Project Managers?

You might ask “Why is this important to project managers?” Isn’t Agile something that only applies to software development? (That’s a common misconception) The truth is that all projects have some level of uncertainty associated with them and if you try to force-fit all projects to a traditional plan-driven project management approach, its just not going to work in many cases. Imagine, for example, trying to develop the next generation of the iPhone or any other new and innovative product. In that kind of project, creativity and innovation is just as important, if not more important, than predictability.

In this new environment, a project manager who only knows how to do a traditional plan-driven approach to project management will be at a serious disadvantage. What makes this even more difficult is that this is not a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think. It’s a matter of figuring out how to blend a traditional plan-driven approach with an adaptive (Agile) approach in the right proportions to fit a given situation.

That requires a lot of skill to do that but it definitely can be done and that is exactly what the Agile Project Management Training I’ve developed is designed to address.

How to Make a Hybrid Agile Process Work and Not Fail

Have you given any thought to “How to make a hybrid agile process work”? I recently saw an article on LinkedIn entitled “Why Hybrid Agile-Waterfall Projects Fail” that caught my eye.  I’m not surprised at this article.  It takes some skill to make a hybrid Agile process work successfully and anyone who would literally try to combine an Agile methodology with a Waterfall methodology to create a hybrid methodology is asking for failure – that’s not the way to do it.

Blending Two Recipes

This should not be a matter of literally combining an Agile methodology and a Waterfall methodology. That would be like trying to take a recipe for Italian food and combine it with a recipe for Chinese food and literally trying to mix the steps and ingredients from the two recipes together to create “Italian-Chinese” food.  A good chef would never even attempt to do that but he/she might create an entirely new recipe that blends together some of the aspects of Italian food preparation with some aspects of Chinese food preparation.

It takes a lot of skill to create an effective hybrid approach and doing it effectively is like the difference between a “chef” and a “cook”.  If you presented a “cook” with a recipe for Italian food and a recipe for Chinese food and asked him to combine the two, I’m not sure what you would get if he/she literally tried to combine the two recipes.  It just doesn’t even make much sense. A “chef”, on the other hand, would take an entirely different approach to create a hybrid of the two.   A chef might not need recipes at all because he/she understands the art at a deeper level.

Creating a Hybrid Approach

When I talk about creating a hybrid approach, I try to avoid the words “Agile” and “Waterfall” if possible because it gives people the impression that you are literally combining two different methodologies together like combining two food recipes.   I prefer to think of a hybrid approach as the appropriate blend of an adaptive approach and a plan-driven approach.  The words “adaptive” and “plan-driven” convey an entirely different meaning than “Agile” and “Waterfall”.

  • It doesn’t mean that you’re trying to literally combine two very different methodologies by mixing them together
  • It means that you’re creating a blended approach with the appropriate amount of emphasis on being “adaptive” versus being “plan-driven”

An Example of a Real Hybrid Approach

Some years ago, I was responsible for managing a very large development program for a US Federal Government agency.  It had a fixed-price contract associated with it and a fairly aggressive delivery schedule but the customer wanted some level of flexibility in the details associated with defining requirements.  I created an approach for this situation that was very successful that I have called “The Managed Agile Development Framework“.

  • It does not attempt to literally combine an Agile methodology and a Waterfall methodology
  • It is simply a matter of wrapping a plan-driven layer at the “macro” level around a standard Agile/Scrum process at the micro level

Here’s a diagram that shows what it looks like:


Managed Agile Development Framework
You might say “That’s not a hybrid Agile-Waterfall model – it’s only a standard Agile development process with a plan-driven layer wrapped around it” and you would be correct.  There has been no attempt to actually mix-and match a phase-gate Waterfall methodology with an Agile methodology.

How To Make a Hybrid Agile Process Work

This is a very flexible model – that is why I call it a “framework” rather than a “methodology”.

  1. You would start out a project by at least developing high-level requirements with estimates of the costs and schedule for completing the project.  Those estimates can be as detailed as you want them to be – that’s what makes this model so flexible.
    • You can have a relatively “thin” layer of planning with very high-level requirements and less-detailed plans or
    • A “thicker” layer of planning with more detailed requirements and planning

    The most important thing is that there has to be a common understanding between the development team and the customer about how detailed the requirements and plan are.
    This model will not work without a spirit of trust and partnership between the customer and the project team.  The customer and the project team must agree to working collaboratively as the project is in progress to further elaborate requirements, continuously refining the plan for completing the project, and resolving any trade-offs that may be necessary to stay within the budgeted cost and schedule.

  2. As the project is in progress, any changes to the project requirements made at the “micro” level need to be fed back into the planning at the “macro” level. By agreement with the customer, there should be enough slack built into the plan so that minor changes can be absorbed easily without a change to the overall plan and only more significant changes might require trade-offs and adjustments. When trade-offs are needed to stay within the budgeted cost and schedule, the customer may need to either:
    • Adjust the planned cost and schedule as necessary, or
    • Reduce the scope of some of the requirements if necessary to fit within the planned cost and schedule.

This is a fairly simple model but it works and it can be easily adapted to a wide variety of projects; however, note that this is not a simple step-by-step cookbook approach with detailed checklists of what to do and fill-in-the-blanks document templates that some project managers are used to. It takes some skill to make this model work successfully.

Matching the Level of Uncertainty in the Project

A good strategy is to match the design of the hybrid approach to the level of uncertainty in the project:

  • A project with a lower level of uncertainty might lend itself to a more plan-driven approach particularly if predictability is important to the customer of the project.  That would mean putting a higher level of emphasis on developing a “thicker” layer of planning at the  macro-level
  • A project with a higher level of uncertainty would probably require a more adaptive approach to further elaborate the plan as the project is in progress.  That would mean that the level of planning at the macro-level would probably be much “thinner”.

How Do You Choose the Right Agile Approach for Your Business?

How do you choose the right Agile approach for your business? Many people will say that you have to convert the entire company and it’s business to an Agile approach in order to make an Agile development process work. That might work for some companies but it isn’t necessarily a good solution for a lot of other companies.

Choose the Right Agile Approach for Your Business

Choose the Right Agile Approach for Your Business

The most important thing to recognize is that the choice of an Agile approach is not a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think.  You have to fit the approach to the nature of the company’s business rather than trying to force-fit the company’s business to one of those extremes.  A major factor in selecting the right approach is the relative importance of two factors in enabling the company’s business success:

Creativity and Innovation versus Predictability, Planning, and Control

It’s not as simple as just becoming “Agile”.

  • A need for emphasizing creativity and innovation would pull you towards an Agile approach
  • A need for predictability, planning, and control would tend to pull you towards a more plan-driven approach (aka what many people loosely call “Waterfall”)

And, I want to emphasize again that those two choices are not mutually-exclusive.  For example, suppose your company is Apple and you need to design the next generation of the iPhone.  Creativity and innovation is obviously important to that effort – otherwise the product would not be very competitive;  however, it also has to be somewhat predictable because you have to hit a certain release date.

Impact of the Company’s Business Model

The nature of an Agile transformation and the relative importance of those two factors will depend a lot on the company’s business model.  Here’s a brief summary – there are two major types of companies that will have a big impact on the nature of an Agile implementation:

  1. Product Development Companies – In a company that is in the primary business of developing products (for example, Apple, Intel, and Microsoft), there is a strong and natural alignment between an Agile development approach and the company’s overall business goals.
    In that kind of environment,  the ability to quickly develop new products and product features is very important for the company to be competitive and successful and, as a result, creativity and innovation play a major role.
  2. Other Companies – In other companies who are not primarily in the business of developing products (For example, Walmart, McDonalds, Hilton Hotels), any development efforts will likely be focused on projects that are not directly related to products they sell to customers.
    Those projects will most likely only indirectly leverage the company’s primary business goals by enhancing operational efficiency, productivity, or some other means.  In that kind of environment, some level of planning and control is important to guide those investments that the company is making in new technology:

    • You want to pick the right combination of project investments that are going to have the greatest impact on the business, and
    • You want to manage those investments to make sure that they do, in fact, provide the return you were expecting

Impact of Financial Planning Model

The way that the company does financial planning is a major factor in determining the right approach:

      1. Product Development Companies – In companies whose primary focus is on product development, a budget is typically established for development and ongoing support of a product or a product line and a lot of discretion is typically given to the Product Manager and the product team in determining how to best utilize that money to maximize the success of that product.  Its relatively easy to apply an Agile development process in this kind of company because there is such a strong and natural alignment between the product decision process and the company’s overall  business management approach.
      2. Other Companies – In other companies that are not primarily in the business of developing and selling products, you’re likely to find a very different environment and the relationship between the project decision process and the company’s overall business management approach is likely to be very different:
        • There are likely to be a lot more projects competing for funding,
        • The relationship of those projects to the company’s business goals is probably more indirect,
        • In many cases, there are dependencies that might require coordinating a change in business processes to implement the project and realize the return, and
        • Many of the projects might be somewhat short-term in nature so there also may be a lot of churning going on constantly.

        That kind of environment obviously calls for more planning and control to maximize the return on investment across a portfolio of potential projects. You just can’t throw money at projects, allow them to go off and figure out the right approach, and expect that somehow it is all going to work out.  The whole process needs to be much more managed.

      What’s the Solution?

      For companies that are not primarily in the business of developing and selling products, it isn’t just a simple matter of making the whole company agile. It typically will require a hybrid approach that mixes some level of traditional plan-driven management with an Agile development process in the right proportions. That takes a lot more skill but it definitely can be done.

    • I think of it like a chess game that may have different levels of management in it.  The challenge is to figure out how many levels are needed; and, for each of these levels, how agile should it be?  Also, how does the whole thing fit together and align with the company’s business objectives?  Naturally, you want to keep it as simple as possible but it’s not as simple as just making the whole company more agile.

    • Related Articles

      I’ve written several previous articles on the relationship of Agile and company culture that are relevant to this:

What Does ‘Waterfall’ Really Mean? How Do People Use That Word?

What does ‘Waterfall’ really mean? Have you ever thought about that? It is often used in comparison to ‘Agile’ but do people know what they really mean when they compare ‘Agile’ to ‘Waterfall’? I think the word ‘Waterfall’ is one of the most loosely-used words in the English language (the word ‘Agile’ is not far behind).

When people talk about ‘Agile’ and ‘Waterfall’, it sounds like they’re comparing two very specific and well-defined methodologies that are binary and mutually-exclusive opposites of each other. However, when you dig into what the words ‘Waterfall’ and ‘Agile’ really mean, you quickly discover that’s a very inaccurate and misleading comparison.

What Does 'Waterfall' Really Mean?

What Does ‘Waterfall’ Really Mean?

Strictly speaking, the word ‘Waterfall’ was originally defined in 1970 by Dr. Winston Royce in his very famous paper:

Dr. Winston Royce’s 1970 Waterfall Paper

He described a model that consists of a sequence of phases where the outputs on one phase flow into the next phase which looks something like this:

It was called ‘Waterfall’ because the results of one phase flow into the next phase like a ‘Waterfall’.

What Was Life Like Prior to ‘Waterfall’?

In order to better understand ‘Waterfall’, it is useful to understand what life was like prior to Waterfall and what problems it tried to solve. What preceded ‘Waterfall’ was a lot of poorly-organized development efforts with little or no structure, discipline, and planning. Some of the major problems with the that approach were:

  • As projects grew in terms of scope and complexity with potentially much larger numbers of developers, it became apparent that a more planned and structured approach was essential to coordinate the work of large development teams
  • The other major problem was that there was very limited predictability over the costs and schedules of software projects, there were many and frequent very significant cost and schedule overruns, and business sponsors demanded some level of predictability

For those reasons, when the Waterfall approach was originally defined, it was a big improvement to go from practically no methodology at all to a very well-defined process that provided:

  • A “road map” to coordinate the work of multiple developers as well as integrating the work with any other essential resources outside of the immediate development teams, and
  • A mechanism to gain some level of control over the scope of software projects in order to get more predictability of project costs and schedules

Many younger people today don’t appreciate that history and just criticize Waterfall as being bad without understanding the problems it was intended to solve.

What Were Some of the Problems With the Original Waterfall Approach?

As with many things, there is a “pendulum” effect and when the Waterfall approach was initially implemented there was somewhat of an over-correction in many cases. The pendulum swung in many projects from almost no control and discipline to very rigid control and discipline. The common practice when the Waterfall process was originally defined in 1970 was a very document-intensive and over-controlled process where you couldn’t exit a phase until all the documentation required to show that the work required for that phase had been completed, reviewed, and approved.

That was a very onerous process and had a number of problems that even Dr. Royce recognized in 1970 when he first defined the process. Some of the most serious problems were:

  • The ultimate user of the software didn’t normally even see the software until all of the development and testing was complete and by that point in time; it was very difficult, if not impossible, to go back and make any significant changes
  • The emphasis on control of scope made the process very inflexible to any changes that might be needed to meet user needs and business goals in an uncertain environment

As a result, there have been many situations where the project may have met cost and schedule goals but failed to provide a sufficient level of business value. Another major problem was that a heavy emphasis on documentation and other overhead required for reviews and approvals made the whole process bureaucratic and not very cost efficient.

How Did ‘Waterfall’ Evolve to Solve These Problems?

Before Agile came into widespread use, many variations on the original Waterfall model and other more iterative models were developed and used to create a more adaptive approach to solve some of these problems. One example was the Rational Unified Process (RUP) whose origins can be traced back to 1996 and 1997. RUP emphasized an iterative development approach to solve some of the problems in the original Waterfall approach. RUP and variations of RUP such as the Enterprise Unified Process (EUP) became very popular in the late 1990’s and early 2000’s.

As a result, if you look at what people have been doing in actual practice over the last 15-20 years, there has been a proliferation of a broad range of many different models (some of which have a very limited resemblance to the original ‘Waterfall’ model as it was defined in 1970). Yet people still loosely characterize all of that as ‘Waterfall’ as if it was one specific, unique and well-defined methodology called ‘Waterfall’ and that is not really the case. The way the word ‘Waterfall’ is used in practice, it actually refers to a broad range of different methodologies.

What’s a More Accurate Way of Describing ‘Agile’ versus ‘Waterfall’?

The common denominator of all the methodologies that people loosely call ‘Waterfall’ is that they emphasize some level of upfront planning and control to try to achieve predictability over project scope, costs, and schedules. For that reason, I think the word “plan-driven” is a more accurate and objective description of what people really mean when they say ‘Waterfall’.

The word ‘Agile’ is also loosely used. We all know that ‘Agile’ is not a specific methodology although many people equate ‘Agile’ with Scrum:

  • Scrum is not really a specific methodology, it is really a framework that is intended to be adaptable to a broad range of situations
  • Agile is not really equivalent to Scrum. There are other Agile methodologies such as Kanban

It’s pretty easy to see that the word ‘Agile’ is also used very loosely to imply a specific and well-defined methodology when that is not the case. The common denominator of methodologies that people call ‘Agile’ is that they are flexible and adaptive and emphasize creativity and innovation in an uncertain environment rather than emphasizing planning and control to achieve predictability with lower levels of certainty. For that reason, I prefer to use the word “adaptive” instead of the word ‘Agile’ when making comparing it to ‘Waterfall’ (plan-driven).

Why Is Comparing “Plan-driven” and “Adaptive” More Accurate and Objective?

Here’s why I prefer to use a comparison of “adaptive” and “plan-driven” rather than ‘Agile’ versus ‘Waterfall’:

  • It’s more accurate – the word “plan-driven” doesn’t imply a specific methodology – it is a characteristic of a broad range of methodologies which I think more accurately describes what people are talking about
  • It’s more objective – the word ‘Waterfall’ has lots of very negative connotations associated with it that go back to the original ‘Waterfall’ model that was defined in 1970 and what people call ‘Waterfall’ today may have little resemblance to the original “Waterfall model that was defined in 1970. The word “plan-driven” doesn’t carry any of that negative baggage

When people in the Agile community compare ‘Agile’ and ‘Waterfall’, it’s usually in the context of Agile is good and Waterfall is bad and that’s really not accurate and objective. Saying “Agile is better than Waterfall” is like saying “A car is better than a boat” – both have advantages and disadvantages depending on the environment that you are in.

  • A plan-driven approach works best in projects that have a low level of uncertainty and require some level of predictability
  • An adaptive approach works best in projects that have a high level of uncertainty and require an emphasis on creativity and innovation to find an optimum solution rather than an emphasis on planning and control to achieve predictability

Overall Summary

I don’t think I have any hope in getting people to stop using the comparison of ‘Agile’ and ‘Waterfall’ – it’s too widely used – I even use it myself sometimes because it is a convenient and simple way of describing something that is actually a lot more complex. I just hope people realize what a huge over-simplification it is and how inaccurate and misleading it can be when people make the comparison of ‘Agile’ and ‘Waterfall’.

I have developed a course called “Learn the Truth About Agile Versus Waterfall” that provides more detail on this to help people see these approaches in a fresh new perspective as complementary to each other rather than competitive. You can check out that free course here:

Free Agile versus Waterfall course

Are Agile and Six Sigma Complementary to Each Other?

I recently responded to a question on an online discussion that asked “Are there companies that use Agile and Six Sigma?”.  This raises an interesting question of “Are Agile and Six Sigma really complementary to each other?”.

 

Are Agile and Six Sigma Really Complementary to Each Other?

The objectives behind numerous approaches such as:

  • Agile and Six SIgma,
  • Agile and Lean, and
  • Agile and Waterfall

are very different and if you pursued these approaches individually and independently of each other, the objectives of each approach are probably somewhat contradictory.  However, all of these approaches can be blended together in the right proportions if they are implemented intelligently in the right context.  That requires a lot more skill and it requires a different kind of thinking to see them as complementary rather than competitive approaches.

The Fundamental Problem

There is a significant fundamental problem that must be overcome to see all of these approaches in a different perspective:

  1. Companies and individuals get enamored with a methodology like Agile or Six Sigma and see it as a “silver bullet” solution to any problem that they might have
  2. They attempt to mechanically force-fit their business to one of those methodologies without fully understanding the principles behind it

An Example With Six Sigma

When I published my first book a long time ago in 2003, Six Sigma was very hot at that time and everyone wanted to “jump on the Six Sigma bandwagon”.  At that time, I researched a number of companies that were doing Six Sigma and other process improvement methodologies and what I saw was this:

  1. Successful Companies – In companies that seemed to do Six Sigma successfully:
    • It wasn’t even obvious that it was Six Sigma and they might not have even called it “Six Sigma”,
    • The implementation wasn’t limited to Six Sigma, they understood the principles behind Six Sigma, and might have blended Six Sigma with other process improvement methodologies, and
    • It was so well-integrated with their business, that it was just a tool that was part of their business rather than a program that was superimposed on their business
  2. Less Successful Companies – In other companies, I saw a much more superficial implementation of Six Sigma that didn’t last in many cases:
    • There was a lot of emphasis on the “mechanics” of doing Six Sigma,
    • There was a lot of “hoopla” about the ceremonies associated with Six Sigma – green belts, black belts, etc., and
    • They openly advertised that they were using Six Sigma to promote themselves

Does that sound familiar?  I think a similar thing is going on with Agile today.

The Key Factor for Success

What I learned from that some of the key factor for success are:

  • Don’t get overly enamored with any methodology (Six Sigma or anything else) and see it as a “silver bullet” for any problem you might have.  Be objective and recognize that any methodology has advantages and limitations depending on the problem you’re trying to solve,
  • Adapt the methodology to fit the problem and the business environment rather than force-fitting your business to some predefined methodology, and
  • Go beyond simply doing a mechanical implementation of any methodology (Agile or Six Sigma) and understand the principles behind it at a deeper level

Are Agile and Six Sigma Really Complementary To Each Other?

Any company who takes that kind of superficial, mechanical approach is going to have difficulty seeing how seemingly competitive and contradictory approaches might actually be complementary to each other. Here are a few examples:

  1. Agile and Six Sigma – On the surface, Six Sigma and Agile would tend to pull you in different directions:
    • Agile emphasizes creativity and innovation as well as flexibility and adaptivity to maximize the business value of the solution
    • Six Sigma emphasizes process standardization and control of a process to minimize process variation
  2. Agile and “Waterfall” – You could make a similar comparison about Agile and Waterfall:
    • Agile emphasizes flexibility and adaptivity and encourages changes as the project is in progress to maximize the business value of the overall solution
    • Plan-driven approaches (what many people loosely call “Waterfall”) emphasize planning and control and discourage changes as the project is in progress to maximize predictability
  3. Lean and Agile – You could also make a similar comparison about Lean and Agile:
    • Lean emphasizes standardizing processes and removing waste from a process to improve process efficiency
    • Agile requires a process to be flexible and adaptive

How Can These Approaches Be Complementary Rather Than Competitive?

How can all of these different approaches that have different objectives that seem to be contradictory to each other actually be complementary to each other rather than competitive? For example, there are many people who see “Agile” and “Waterfall” as binary and mutually-exclusive choices and don’t see any way that the two approaches could be combined.

The key to seeing these approaches as complementary rather than competitive is to understand the fundamental principles behind the approach at a deeper level rather than getting lost in the “mechanics” of the approach. For example:

  • “Waterfall” – The word “Waterfall” has some well-ingrained connotations associated with it that are not necessarily totally accurate.  It invokes an image of a very bureaucratic process with phases that are rigidly-controlled so that you don’t exit that phase until you have completed all of the onerous documentation requirements for exiting that phase.   That process that was originally documented by Winston Royce in the 1970’s and is rarely used in that form in practice today; however, the word “Waterfall” continues to be used very loosely for any process that is not Agile.
     

    The fundamental essence of what people call “Waterfall” is that it is a “plan-driven” approach – that is why I prefer to call it “plan-driven” instead of “Waterfall”.  A “plan-driven” approach does not necessarily have to have a rigid and inflexible plan and it also doesn’t necessarily have to have many of the other attributes of the original Waterfall approach such as excessive reliance on documentation and phases that have controlled phase transitions.

  • “Agile” – The word “Agile” has also taken on some very heavily-ingrained connotations in practice today.  When you say the word “Agile” many people associate it with Scrum and think that you can’t be “Agile” unless you are really following all the rituals and ceremonies associated with Scrum religiously.
     

    The fundamental essence of “Agile” is being flexible and adaptive to maximize the value of the solution that is being produced.  I prefer to use the word “adaptive” rather than “Agile” for that reason.  The word “adaptive” is a more general term that does not carry some of the heavily-ingrained connotations associated with the word “Agile”.

  •  

  • Lean – The essence of Lean is the reduction of waste in a process and there is absolutely nothing wrong with that as long as people don’t become obsessive about reducing waste at the expense of other objectives.  For example, in an Agile process, it is impossible to completely remove waste; and, at the same time, attempt to maximize the flexible and adaptive which is the essence of being Agile.  However, there is nothing wrong with trying to reduce waste in an Agile process as long as it is done intelligently and in the right balance with other objectives.
  •  

  • Six Sigma – The essence of Six Sigma is attempting to standardize processes and reduce variation in processes.  If you became obsessive about pursuing that goal, it would also not be very consistent with being Agile; however, there is absolutely nothing wrong with attempting to standardize processes to some extent as long as it is also done intelligently and in balance with other objectives.

The importance of “Systems Thinking”

A fundamental skill for doing this successfully is “Systems Thinking”. Here’s a definition of “Systems Thinking”:

“Traditional analysis focuses on separating the individual pieces of what is being studied; in fact, the word ‘analysis’ actually comes from the root meaning ‘to break into constituent parts’. Systems thinking, in contrast, focuses on how the thing being studied interacts with the other constituents of the system – a set of elements that interact to produce behavior – of which it is a part. This means that instead of isolating smaller and smaller parts of the system being studied, systems thinking works by expanding its view to take into account larger and larger numbers of interactions as an issue is being studied.”

Overview of Systems Thinking – http://www.thinking.net/Systems_Thinking/OverviewSTarticle.pdf

 

What is Systems Thinking?

This kind of thinking is essential for seeing these seemingly contradictory approaches in a much broader context of how these objectives can interact in complementary ways rather than being competitive.

Overall Summary

It is very possible to blend together different approaches that are seemingly in conflict with each other as long as it is done intelligently. It requires:

  • Understanding the fundamental principles behind each approach rather than getting lost in the mechanics,
  • Using a systems thinking” approach to see how these seemingly contradictory approaches might actually be complementary to each other rather than competitive, and
  • Learning to fit the methodology to the problem rather than force-fitting a problem to any given methodology or combination of methodologies

This is exactly the approach behind the Agile Project Management online training courses I’ve developed.

Is Project Management Obsolete – What Do You Think?

Is project management obsolete?  I don’t think that “project management” is obsolete but I do think that some traditional roles of a “Project Manager” are becoming obsolete in projects that require a more adaptive approach.  I also think that there’s a need to redefine what “project management” is if it is to continue to thrive in the future.  There is a need to:

  • Separate the functions of “project management” from some of the traditional roles that have been played by a “Project Manager”, and
  • For the project management profession to “reinvent” itself and develop a broader view of what “project management” is if it is going to continue to thrive and remain relevant in today’s world.

Is Project Management Obsolete

Examples of Companies and Professions Reinventing Themselves

Any company or profession that doesn’t change and adapt to changes in the world around them runs the risk of becoming stagnant and no longer relevant. Here are a couple of examples:

  • American Express – American Express is a company that has been around for more than 150 years and has had to reinvent itself a number of times over that time. American Express started out in 1850 shipping boxes on railway cars. That business went very well for a while:

    “For years it enjoyed a virtual monopoly on the movement of express shipments (goods, securities, currency, etc.) throughout New York State.” (Wikipedia)

    Can you imagine where American Express would be today if it still defined its business primarily around shipping boxes on railway cars?

    American Express has continued to reinvent itself over-and-over again to remain a vibrant and competitive company.  Here’s another example – At one time not too long ago, American Express had a fairly large area of business associated with providing travel services to companies.  They provided on-site travel agents to help companies plan travel, book travel reservations, and other related services. In recent years, that business has declined as newer internet-based services displaced the need for on-site travel agents.  That’s another significant adjustment that American Express has had to make to adapt to changes in technology and the marketplace.

  • Quality Management – In the early 1990’s I worked in the Quality Management profession with Motorola. Prior to that time, Quality Management was heavily based on a quality control approach that relied on inspectors to inspect products for defects.That process was very reactive and inefficient and companies like Motorola began implementing a much more proactive approach to quality management that was based on eliminating defects at the source rather than finding and fixing them later.  That’s how Six Sigma was created at Motorola at that time.That caused a major transformation in the Quality Management profession.  Instead of being in control of quality through quality control inspectors, Quality Managers had to learn to distribute some responsibility for quality to the people who designed and manufactured the product and play more of a consultative and influencing role.  When I worked for Motorola in the early 1990’s,  my manager used to tell me that:

    “Our job is to teach, coach, and audit – in that order”

    That turned out to be a much more effective approach but it was a gut-wrenching change for many people in the Quality Management profession who were used to being the ones who owned responsibility for quality and were in control of quality.

    I published my first book in 2003 which was called “From Quality to Business Excellence“.  That book was designed to help quality professionals understand this transition and I also gave numerous presentations at that time to ASQ (American Society for Quality) chapters to help them better understand and adapt to the transformation that was taking place.   At that time, there were a lot of people in the local ASQ chapters had difficulty adapting to that change and who were out of work.

How Does This Relate to Project Management?

For many years, the project management profession has been dominated by an approach that emphasized planning and control. A project was deemed to be successful if it delivered well-defined project requirements within an approved budget and schedule. That approach hasn’t changed significantly since the 1950’s and 1960’s but we live in a different world today. There are two major factors that are creating a need for a different approach in today’s world:

  • Levels of Uncertainty – There is a much higher level of uncertainty because problems and solutions tend to be much more complex.  This is particularly true of large software systems. With a high level of uncertainty; it is difficult, if not impossible, to define a detailed solution to the problem prior to the start of the project.   The example I use in my training is “finding a cure for cancer”.  Can you imagine attempting to develop a detailed project plan for that kind of effort?  There is just too much uncertainty.  Instead of getting bogged down in trying to develop a detailed project plan upfront, it would be much better to get started and use an iterative approach to attempt to converge on a solution as the project is in progress.
  • Increased Emphasis on Innovation – In many areas, competitive pressures require a significant level of innovation in new product development.  In these areas, creativity and innovation are much more important than planning and control.  For example, think of what a company like Apple has to do to develop a new iPhone.  Do you think that they start with a detailed plan based on some well-defined requirements?  I don’t think so.

An Agile project management approach is very well-suited for a project that:

  • Has a high level of uncertainty, or
  • Requires an emphasis on creativity and innovation rather than an emphasis on planning and control.

An Agile approach uses a very different approach to project management.  In an Agile project, you probably won’t find someone at the team level called a “Project Manager” but that doesn’t mean that there is no “project management” going on:

  1. It’s a different kind of project management that is focused on an adaptive approach to project management to optimize the business value the project produces rather than a plan-driven approach to project management that is oriented around simply meeting cost and schedule goals for defined requirements.
  2. The project management functions that might normally be performed by someone called a “Project Manager” have been distributed among the members of the Agile team:
    • Each member of the team is responsible for planning, managing, and reporting on their own tasks and working with other members of the team as necessary to integrate their efforts
    • The Scrum Master plays a facilitation role and is responsible for removing obstacles if necessary
    • The Product Owner plays an overall management role to provide direction and decisions related to the direction of the project and is ultimately responsible to the business sponsor for the overall success or failure of the project from a business perspective

What Needs to be Done to Adapt to This New Environment?

In today’s world:

  • There are many project managers who have been heavily indoctrinated in a traditional plan-driven approach to project management who might attempt to force-fit all projects to that kind of approach
  • There are also many project managers who are used to a project management approach that relies heavily on well-defined document templates and checklists to define how the project is managed

In my book, I use the analogy of a project manager as a “cook” versus a project manager as a “chef”:

  • “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.” (Cobb – The Project Manager’s Guide to Mastering Agile)

I think that analogy captures the challenge for the project management profession very well – In today’s world we need fewer “cooks” and more “chefs”:

  • Project managers need to learn how to blend an Agile (adaptive) approach with a traditional plan-driven approach in the right proportions to fit the nature of the problem.  Force-fitting all projects to a traditional plan-driven project management approach is not likely to be very successful
  • This new environment “raises the bar” considerably for project managers and requires a lot more skill.  It is not a simple matter of filling in the blanks in well-defined project templates and following project checklists based on PMBOK®.

What Has Been Done to Transform the Project Management Profession?

PMI® has begun to recognize the need to deal with this challenge and has made steps in that direction but much more needs to be done:

  1. The PMI-ACP® certification is a step in the right direction but it doesn’t go far enough in my opinion.  It recognizes the need for project managers to have an understanding of Agile and Lean but it is only a test of general Agile and Lean knowledge and doesn’t really address the big challenge that project managers have of figuring out how to blend those approaches with a traditional plan-driven approach to project management.
  2. PMI® still treats Agile and traditional plan-driven project management as separate and independent domains of knowledge with little or no integration between the two. PMBOK® version 6 will have some added material on how the various sections of PMBOK® might be applied in an Agile environment but that also doesn’t go far enough in my opinion. The whole idea of PMBOK® is not very compatible with an Agile approach.
    • Agile requires a different way of thinking that is much more adaptive and you shouldn’t need a 500+ page document to give you detailed instructions on how to do Agile.
    • The whole idea of developing a knowledge base associated with Agile and only changing it every five years is difficult to imagine
  3. Much of the training that is available to project managers today on Agile only addresses the basics of Agile and Scrum.  You have to understand the principles behind Agile and Scrum at a much deeper level to understand how to successfully adapt those approaches to different kinds of projects.  You can’t just do Agile and Scrum mechanically.

We need to go beyond these steps and “reinvent” what “project management” is (just as American Express and other companies have had to reinvent the business that they are in).  Here’s how PMBOK® currently defines “project management:

“Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.  Project management is accomplished through the appropriate application and integration of the 47 logically grouped project management processes, which are categorized into five Process Groups.”  (PMBOK® version 5)

There are at least two major problems with that definition:

  1. The phrase  “to meet the project requirements” implies that a project is limited to meeting defined requirements.  In today’s world, a project manager should be capable of taking on a project with broadly-defined objectives, figure out what needs to be done to accomplish those objectives, and also figure out what methodology is best suited for managing that effort
  2. The phrase “application and integration of the 47 logically grouped project management processes” implies that there is a defined process approach for project management rather than an empirical approach that is used in an Agile environment

Summary – Is Project Management Obsolete

Project Management certainly isn’t obsolete but the “handwriting is on the wall” that change is definitely needed for the profession to continue to grow and thrive.  The need for change doesn’t always hit you in the face immediately. Many times it comes about subtly and it may not be that obvious at first but I can certainly see the early signs that a change is needed:

  • I gave a presentation at a PMI chapter in New York city this week and it was an excellent group of people but attendance was much lower than in the past. This presentation drew about 75 people and previous PMI chapter presentations I’ve given in New York City have drawn about 200-300 people.
  • I also met a number of people in that presentation who are out of work and looking for new opportunities

Those are obvious early warning signs to me that a transformation is needed to redefine and rejuvenate the project management profession.  It reminds me a lot of what I saw in the ASQ chapters I presented to about 15 years ago.

I am very passionate about helping the project management profession recognize the need for this transformation and helping project managers to develop the skills to successfully make this adaptation.  That’s the essence of the three books I’ve published on Agile Project Management and of the online Agile Project Management training I’ve developed.

Blending Agile and Traditional Project Management

Protected with SiteGuarding.com Antivirus