Category Archives: Agile and PMI

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.

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

The New PMI PDU System

The New PMI PDU System has raised a number of questions. As many people may know, PMI has recently announced some significant changes in the process for claiming and reporting PDU’s. This new change went into effect on December 1, 2015. With this new change, PDU’s need to be split into three different categories:

  • Technical
  • Leadership
  • Strategic & Business Management

In addition, each major certification (e.g., PMP, PMI-ACP) requires you to achieve a certain number of PDU’s in each of these categories in order to renew your certification (Total number of PDU’s is no longer sufficient).

I applaud this change. It is going in absolutely the right direction to elevate the project management profession and is very much in line with the direction I’ve been developing in my own courses. The thinking behind this change is that a project manager can no longer be just a technical administrator who manages project plans and schedules and that sort of thing. The essence of this change is that, in addition to that kind of technical project management role, a project manager must also have:

  • Strong leadership skills (not just simply coordinate resources from a variety of functional departments) and
  • Be able to play a value-added role that connects projects with driving strategic business goals (not just simply meeting project requirements and controlling budgets and schedules)

It’s very apparent to me that we are in the midst of a major transformation of the whole project management profession and you can see this clearly with Agile:

  • The role of a project manager at the team level in a true Agile environment does not exist anymore in many environments, and
  • If there is a role for a project manager, at all, in an Agile environment, it is a very different kind of role and may be at a higher level that requires strong people leadership skills as well as the ability to help define a project management approach that is well-aligned with the company’s business

These are exactly the challenges I have tried to address in all of my courses to help the project management profession move in this direction!  All of my courses are eligible for PDU’s and you can find more information on all of my courses at the following location:

http://managedagile.com/training-courses/

Agile Project Management Book of Knowledge

Will there ever be an “Agile Project Management Book of Knowledge”? I’ve written several posts on comparing Agile and PMBOK.  It’s something like comparing apples and oranges:

  • PMBOK is over 500 pages long and attempts to provide a detailed checklist of guidelines for almost any conceivable situation involving project management.
  • Agile takes a totally different approach – defining some basic values and principles and leaving a lot of room for interpreting those values and principles in the context of the situation you’re in (at least that’s the way it is meant to be implemented, in my opinion).

For that reason, I don’t think that there will ever be an Agile version of PMBOK; however, I think there is value in having at least an outline of topic areas that are important for people to know about who are interested in assuming an Agile Project Management role.  Here’s what led me to that conclusion…

I’m developing a complete learning path consisting of about a dozen training courses for PMI-ACP certification.  This is not a typical “exam prep” course – I am totally against many of the “exam cram” courses that are on the market that are just focused on helping students cram some knowledge just to get through passing the PMI-ACP exam and not much more.  My philosophy is that people who are sincerely interested in becoming an excellent Agile Project Manager need to go well beyond passing the PMI-ACP exam and think well beyond simply obtaining PMI-ACP certification for a number of reasons:

  • The PMI-ACP exam is very limited in scope – it doesn’t address some of the things that I think are really important for an Agile Project Manager to know like how to integrate Agile and plan-driven approaches in the right proportions to fit a given situation.
  • The PMI-ACP exam also has a lot of useless and outdated information in it.  For example, how many people use the “Crystal” methodology any more?
  • It also relies heavily on some reference books that are also very outdated – Jim Highsmith’s book on Agile Project Management which was originally published in 2004 and republished in 2009 is one that PMI treats like the “Bible” of Agile Project Management.   I have a lot of respect for Jim Highsmith – he really was a very early pioneer in developing the initial concept of Agile Project Management but the thinking about what “Agile Project Management” is has evolved a lot since that time.
  • PMI also seems to have the delusion that you can just superimpose many traditional plan-driven concepts on top of Agile and I don’t believe that to be the case.  Agile really requires rethinking a lot of things we’ve taken for granted about project management for a long time, it really requires a very different way of thinking, and many well-accepted project management practices just aren’t very appropriate and/or useful in an Agile environment .  Here are a couple of examples of that:
    • The PMI-ACP exam requires you to know a lot about how to do complicated financial return calculations such as NPV, IRR, ROI, etc. – there seems to be an implication that an Agile Project Manager would really use that in the real world and I doubt that to be the case.  You rarely would know enough about a project upfront to do that kind of sophisticated financial analysis on an Agile project.
    • Earned Value Management is another example – how many people have ever used EVM on an Agile project?  The concept isn’t bad, but making it work in actual practice is almost impossible for many of the same reasons as the sophisticated financial analysis tools.  I have used EVM once for a government project because we were required to use it and report progress against earned value metrics but it was a joke…people had to play a lot of games with the numbers to satisfy the government’s requirements for EVM reporting.

All that being said, I think there is some value in PMI-ACP certification and passing the exam because it has gained some recognition and it is certainly a lot better than some of the other alternatives (Don’t get me started on talking about the CSM certification). However, you just need to realize that there’s a lot of useless information that you have to know just to pass the exam and you also need to be realistic enough to recognize that becoming a really effective Agile Project Manager it isn’t just a matter of passing the exam and getting the PMI-ACP certification.

The overall learning path I’m developing is built around those assumptions.  It is designed to give someone the knowledge that they need to pass the PMI-ACP exam (including a lot of information that I think is useless in the real world but you have to know because its on the exam), but the real focus is well beyond that and on giving someone the knowledge that they need to be a really good Agile Project Manager.

Another major problem I’ve had to deal with is that, in my opinion, the current way that the areas covered on the PMI-ACP exam are defined and organized is very disjoint, not well-organized, and incomplete.

  • The “Domains and Tasks” that are covered on the exam don’t exactly map to the other areas of “Knowledge and Skills” and
  • The “Knowledge and Skills” areas don’t map very well to the topics in “Tools and Techniques”.
  • I think PMI will also acknowledge that the topics in all of those areas are not meant to be a complete list – they are only representative examples of potential topics in that area.   PMI points to a number of reference books that are suggested reading and almost anything in any one of those reference books is fair game for being on the exam even though some of those books are fairly old and the list hasn’t been updated in some time.

To deal with that challenge, in planning for developing the overall learning path I’m working on, I needed to create a well-organized outline of topics that I thought needed to be covered.  As I develop the new courses in the current learning path I’m developing, I will be cross-referencing the material in those courses against that topic outline.   This topic outline is a “work in progress” at the moment; I’m sure that it is not anywhere near 100% complete, but I would be willing to share it with anyone who would like to review it and give me your comments and suggestions to help further develop this topic outline.  Here’s the kind of input I’m looking for:

  • Is it complete?  What topics have I left off that are important either for passing the PMI-ACP exam or for a real-world Agile Project Management role?
  • Do you agree with how it is organized?  I’ve tried to develop one overall integrated topic list that is much more consistent and well integrated than the way the various PMI-ACP exam topics are organized.
  • What other suggestions do you have for further developing this topic list?

If you’re interested in reviewing this list and providing feedback, please send me an e-mail and I’ll send you a copy to review.  Please don’t ask for a copy unless you are seriously committed to reviewing this document and providing feedback:

Send email to Chuck

Will PMBOK Ever Be Compatible With Agile?

Will PMBOK ever be compatible With Agile? I’ve been working with Boston University and a number of other universities on developing an Agile Project Management curriculum. In developing a curriculum like this, there are two aspects of the work to be done:

  1. Synthesizing or developing the body of knowledge that you need to communicate, and
  2. Designing the course materials to teach that body of knowledge

If the body of knowledge associated with Agile Project Management were available in some well-documented form like PMBOK(R) that integrated both traditional plan-driven project management knowledge with Agile, the task of developing a course to teach that body of knowledge would be much easier, but I’m not sure if the body of knowledge associated with Agile Project Management will ever exist in that form.

Some books have attempted to map PMBOK(R) to Agile principles and practices (Michelle Sliger’s Book, “The Software Manager’s Bridge to Agility” is an example). Although you can make some general comparisons, it’s like comparing apples and oranges, in my opinion – there may be some similarities, but the whole philosophy behind PMBOK(R) is very different from the philosophy behind an Agile approach which makes it very difficult, if not impossible, to combine the two. Here’s why:

The Difference Between Explicit and Tacit Knowledge

PMBOK and Agile are based on two very different approaches to knowledge management:

    • Explicit Knowledge – is “codified knowledge found in documents, databases, etc.”
    • PMBOK relies very heavily on explicit knowledge – it attempts to codify a checklist of things to consider in almost every conceivable project management situation

    • Tacit Knowledge – is “intuitive knowledge and know-how, which is:
      • “Rooted in context, experience, practice, and values”
      • “Hard to communicate – it resides in the mind of the practitioner”
      • “The best source of long-term competitive advantage and innovation”
      • “Is passed on through socialization, mentoring, etc.” – it is not handled well by systems that try to document and codify that knowledge.
      • Agile takes a very different approach which is more consistent with tacit knowledge – instead of providing a detailed comprehensive checklist of things to consider in a broad range of different situations, Agile provides some general, higher level principles and values that need to be interpreted in the context of the situation.

“Source: KMT – An Educational KM Site, http://www.knowledge-management-tools.net/different-types-of-knowledge.html

The Difference Between a Defined Process Model and an Empirical Process Model

That doesn’t mean that PMBOK is bad and Agile is good which is an inference that many people might jump to. That’s like saying “a car is better than a boat”. Neither one is inherently good or bad and each has advantages and disadvantages depending on the environment you’re in. An explicit knowledge approach such as PMBOK is very consistent with a “defined process model”. A “defined process model” looks something like this:

Defined Process Model

The characteristics of a defined process are:

  • The process is repeatable and doesn’t change from one project to the next
  • The process is predictable – given a similar set of inputs, it should produce a predictable set of outputs

Agile is based on more of a tacit knowledge approach which is more consistent with an empirical process model which looks something like this:

Empirical Process Model

The process is intended to be adaptive to fit the situation based on continuous improvement and learning. Scrum is a good example of an empirical process model.

Can PMBOK Be Modified to Integrate Agile Thinking?

There have been some attempts recently to make PMBOK(R) more compatible with adaptive project management approaches:

  • PMBOK(R) version 5 which has been released incorporates some more inclusion of adaptive thinking but it is still heavily oriented around a plan-driven approach
  • PMI(R) has introduced the “Software Extensions to the PMBOK(R) Guide” which has a little bit more mention of Agile but is still limited

I participated in a LinkedIn discussion group some time ago where someone made the comment that PMBOK was very adaptive to an agile approach and challenged me to defend why that was not so. My response was that almost anything can be adapted to a different purpose but that doesn’t mean it is really optimized for that purpose. I could say a piece of sheet metal is adaptable to be used for writing a book because I can write on it like a piece of paper but is it really optimized for that purpose? (I don’t think so) Extending PMBOK to be a single knowledge base to cover both Agile and traditional plan-driven project management would be like modifying a car so that it could also be used as a speed boat. You might be able to do it, but the results are not likely to be very optimal.

Patching up PMBOK(R) to make it more “Agile” is likely to have significant limits for that reason. Agile is a different way of thinking, in my opinion – it acknowledges that we don’t know everything we need to know and puts an emphasis on rapid and adaptive learning.