Multi-Dimensional Project Management

I recently wrote a post on “Adaptive versus Plan-driven Project Management”. It occurred to me that this same framework would be useful to help people understand the migration that I believe is happening in the project management profession. Here’s how I see the migration of project management roles that is likely to take place in the future:

Project Management Migration

I don’t think that anyone today would disagree that “Project Management”, as we’ve known it, is heavily defined by plan-driven principles and practices as shown by the oval in the left-hand column of this diagram and there are many stereotypes that heavily associate “Project Management” with plan-driven practices. What I believe is likely to happen within the project management profession in the future is this:

  • At a team level, a large percentage of project management roles are likely to migrate towards a more adaptive approach over some period of time. That means that many of those project management roles might disappear and project managers who are only qualified to do plan-driven project management at a team level may have to move in one of two different directions:
    • Move up to assume a higher-level enterprise-level role managing larger, more complex projects
    • Develop more adaptive project management skills
  • Project Managers who are already managing larger, more complex projects and enterprise-level projects may be less impacted by this migration; however, even at that level, the demand for project managers who only know how to do plan-driven project management will likely decline significantly.
    • Some of these new roles may not even be recognizable as we know project management today and may not even have the title of “Project Manager” associated with them. For that reason, I think we need to shift our thinking about what “Project Management” is. Instead of thinking of it as a narrow vertical column that is dominated by plan-driven thinking, what I believe is needed is more of a broader, multi-dimensional view of project management that goes beyond just doing traditional, plan-driven project management functions and also embraces a more adaptive approach to project management.

      In my opinion, project managers of the future will need to take on a broader range of roles and must be able to operate in either a plan-driven role or a more adaptive project management role and should be able to select the appropriate blend of those two approaches to fit a given situation rather than force-fitting all projects to a plan-driven approach.

      It seems to me that the Project Management profession needs an image makeover to shift the image of how people think of what “Project Management” is to prepare people for this migration that I believe is likely to happen. I think that there are a lot of people in the project management profession who are in “denial” and seem to think that the way we’ve been doing project management will go on unchanged into the future. I hope this post has helped people more clearly see this migration trend.

      (See my blog post on “Reinventing Project Management” for more on this.)

Adaptive versus Plan-driven Project Management

I’ve written several articles on the subject of why the comparison of “Agile versus Waterfall” that is so widely used is so inaccurate and misleading. Check it out here:

Learn the Truth About ‘Agile versus Waterfall’

There’s a lot of reasons why that comparison isn’t very meaningful and can be misleading – What is Agile? What is Waterfall? What are you comparing to what? Is it really a meaningful comparison? (I don’t think so)

A much more objective and meaningful way of comparing different methodologies is needed and I think the comparison of “Adaptive” versus “Plan-driven” is much better-suited for that purpose. Here’s how those terms are defined:

  • Plan-driven – “Plan-driven software development is a more formal specific approach to creating an application. Plan-driven methodologies all incorporate: repeatability and predictability, a defined incremental process, extensive documentation, up-front system architecture, detailed plans, process monitoring, controlling and education, risk management, verification and validation” (Source: http://en.wikiversity.org/wiki/Plan-driven_software_development
  • Adaptive – An “Adaptive” approach, on the other hand is characterized by having a less well-defined plan that is more adaptable to fit the situation as the project progresses. It’s more of a rolling-wave planning approach where the plan evolves as the project evolves.

This is not a binary, all-or-nothing choice between 100% plan-driven and 100% adaptive:

  • You don’t typically find many situations that have an absolutely rigid plan down to the smallest detail that is not subject to any kind of change and
  • You don’t typically find situations that are totally unplanned where you just start doing something without any kind of plan and make up the plan as you go.

Most situations lie somewhere between those two extremes – there is a continuum of different approaches from a heavily plan-driven approach at one extreme and a heavily adaptive approach at the other extreme with lots of alternatives in the middle. If you were to plot different approaches on this continuum, here’s a sketch of what it might look this:

Adaptive vs Plan-driven

Here’s some notes on this diagram:

  • This is not meant to be an exhaustive and comprehensive diagram – it is simply an illustration showing a few examples
  • Each of these methodologies can be used in a range of situations – for example, Scrum can be used in a range of situations that have varying levels of adaptivity; however, it would be difficult to make Scrum work in a heavily plan-driven approach
  • However, by putting a plan-driven “wrapper” around Scrum, you can create a hybrid approach that provides a plan-driven shell at the project level but retains most of the flexibility of Scrum at the team level
  • Kanban is generally more adaptive than Scrum because it is typically used in more reactive situations that are less planned (like a customer service process)

There is no “good” and “bad” judgment in characterizing a methodology as “adaptive” or “plan-driven”. Neither an adaptive methodology or a plan-driven methodology is inherently good or bad just because it is adaptive or plan-driven. The problem comes up when they are misused – for example, when you try to use a heavily plan-driven methodology like Waterfall for a situation that has a lot of uncertainty in it and calls for a more adaptive approach.

Why is this important? The traditional comparison of “Agile versus Waterfall” is almost meaningless and very misleading. It frequently is used judgmentally that “Waterfall” is bad and “Agile is good. That leads people to think of those two approaches as binary, mutually-exclusive choices; and, as a result, people many times tend to force-fit a project to one of those extremes. A much better approach, in my opinion, is to view these approaches from a more objective perspective and fit the approach to the nature of the problem based on the characteristics of the methodology and the problem.

Learn the Truth About “Agile” versus “Waterfall”

Background

How many times have you heard people compare “Agile versus Waterfall”? It happens a lot, I do it myself, and I keep hearing presentations that talk about how Agile has displaced “Waterfall”. But, if you really think about it, I don’t think that’s a very meaningful comparison and it’s out-of-date – true “Waterfall”, as a methodology, died a long time ago for most projects outside of some specialized areas like construction yet people continue to make that comparison.

The problem is that the word “Waterfall” is used very loosely and indiscriminately. In many cases, when people use the word “Waterfall”, they’re not using it to refer to the specific “Waterfall” methodology that was originally defined by Winston Royce in the 1970’s, they’re using it loosely to refer to a general style of project management that obsessively emphasizes predictability and control over agility.

The word “Waterfall” actually has some fairly specific connotations. For example, a true “Waterfall” project is broken up into phases based on functional activities (design, develop, test, etc.) that typically happen sequentially with phase gates that control the progression from one phase to the next. I think the usage of that methodology for software development today is practically zero, yet people continue to compare Agile to “Waterfall”.

Some Examples of Sloppy Terminology

Don’t get me wrong – I think Agile has huge benefits. I just want people to objectively understand the benefits of Agile versus Waterfall and the sloppy use of terminology to compare the two is often misleading and confusing. Here are a couple of examples I’ve taken from some real world sources to illustrate what I mean by sloppy use of technology when people talk about “Waterfall”:

Blue Line

From the 2011 Chaos Report: “Agile Succeeds three times more often than Waterfall”
The report goes so far as to say, “The agile process is the universal remedy for software development project failure.”

What do they mean by “Waterfall”? (Are they talking about a specific methodology – like the Waterfall that was defined by Winston Royce in the 1970’s or are they talking about a broader range of plan-driven methodologies?)

Blue Line

From an invitation to attend a local Agile group presentation: “It would be so easy if everyone at our companies just used Scrum — or at least Agile. No one would lean on the team for dates and deadlines, and everyone would know that change is a good thing. It’d be one great big happy project management family. But let’s face it — an all-Agile organization isn’t always possible. Maybe you have a Project Management Office (PMO). Maybe you work for a government contractor. Maybe you have regulatory requirements. Maybe you’re the first Scrum/Agile project at your company. Maybe your company simply *likes* it this way. Whatever the reason, Agile teams frequently report into Waterfall organizations.”

What do they mean by a “Waterfall organization”?

Blue Line

When people use the word “Waterfall” like this, I’m tempted to ask, “Which aspect of ‘Waterfall’ are you referring to?”

  • Are you referring to the phase gate approach where a project is broken up into phases and there is a phase gate for approval to transition between phases? I don’t think that approach has been widely practiced for years for software development projects and even Winston Royce himself had reservations about it
  • Are you referring to an over-reliance on documentation? That is a more legitimate comparison because Winston Royce did come out very strongly in support of a lot of documentation, but that shouldn’t imply that an Agile project has no documentation whatsoever.
  • Are you referring to the tendency to plan an entire project upfront before starting the project and then manage changes to the project requirements through change control? That also might be a legitimate comparison, but it also shouldn’t be meant to imply that an Agile project shouldn’t do any planning upfront.
  • Are you referring to the practice of attempting to complete all of the project requirements all at once? Long before Agile became well-known, iterative approaches like the Rational Unified Process (RUP) provided a way to solve that problem and break up a project into iterations.

A More Meaningful Comparison

A more meaningful and more objective comparison is between an “adaptive” approach to project management and a “plan-driven” approach to project management. “Plan-driven project management” is a style of project management that is applied to projects where the requirements and plan for completing the project can be defined to some extent prior to implementing the project. In contrast, an “adaptive” style of project management starts the implementation of a project with a less well-defined plan of how the project will be implemented and the requirements and plan for the project are expected to evolve as the project progresses.

No project is ever totally plan-driven or totally adaptive; you won’t find many projects that start out with an absolutely rigid plan that is not expected to change at all, and you won’t find many projects that have no plan whatsoever of how the project will be done. There is a broad range of alternative approaches between those two extremes as shown in the diagram below:

Agility Range

It is a matter of choosing the right level of upfront planning to be applied to a project based on the level of uncertainty and other factors in the project and it takes some skill to do that.

There is nothing inherently wrong with either of these approaches (adaptive or plan-driven). They both have advantages and disadvantages for a given project and they should be seen more as complementary approaches rather than competitive. Instead, many people see “Agile” and “Waterfall” as binary and mutually-exclusive choices and that causes people to try to force-fit a project to one of those extremes rather than selecting and tailoring the approach to fit the project. For example,

  • If I were to set out to try to find a cure for cancer and I attempted to apply a highly plan-driven approach to that project, the results would probably be very dismal
  • Similarly, if I tried to use an agile approach for building a bridge across a river, the results would be equally dismal

Why does that happen? It takes much more skill to fit a methodology (or combination of methodologies) to a project – you have to know a broader range of methodologies and you have to understand the principles behind the methodologies at a deeper level to know how to tailor the methodology and blend different methodologies together to fit a given situation. Some people are primarily skilled in one particular methodology and tend to implement that methodology mechanically “by the book”. It’s like being a carpenter and the only tool in your tool bag is a hammer.

Overall Summary

The impact of misusing the word “Waterfall” is significant:

  • It causes people to “throw out the baby with the bath water”. By misusing the word “Waterfall” and categorizing all plan-driven approaches as “Waterfall”, people tend to dismiss any form of plan-driven approach and to regard any kind of upfront planning as inconsistent with an Agile project.
  • It has caused a lot of polarization between the traditional project management community and the agile community. The perception is that project managers are associated with the Waterfall approach and, as a result, project management skills are not needed because the Waterfall approach is an out-of-date approach for many projects.

The true Waterfall approach has been obsolete for many projects for a long time (the exception being some selected industries like construction where it is still very useful and relevant). Even prior to Agile, many people were widely using iterative approaches like RUP for software development in place of Waterfall. So, I don’t think comparing Agile to Waterfall is very meaningful any more, but its very difficult to get people to stop thinking in those terms because it has been so prevalent for such a long time.

The difference between a highly adaptive project and a highly plan-driven project is how much of that planning is done upfront in the project rather than being deferred till later. It’s not a black-and-white decision to have a totally plan-driven approach or a totally adaptive approach and it requires some skill and judgment to determine what level of upfront planning makes sense in a given project. When people present this decision as “Agile versus Waterfall” it distorts what the real decision is and makes it look like a binary, all-or-nothing choice and that’s not the case.

Additional Resources

I’ve created a new online training course on Udemy that provides more information on this topic:

https://www.udemy.com/learn-the-truth-about-agile-versus-waterfall/#/

This new course on Udemy is free.

Learning the Truth About “Agile” versus “Waterfall”

When I originally created this post, it drew almost 200 hits in the first day which is an indicator of how important this topic is! In response to that level of interest, I’ve expanded the original video I posted below on YouTube and turned it into a 30 minute Udemy course. The new Udemy course is at the following location:

https://www.udemy.com/learn-the-truth-about-agile-versus-waterfall/#/

This new course on Udemy is free. The original 10 minute video is still available on YouTube at the link shown at the end of this article. Here’s a summary of both the training course and the shorter video…

Many businesses and project managers are faced with a choice of choosing a traditional plan-driven approach (or what is sometimes called “Waterfall”) or a more Agile approach for critical projects which can be a very important decision with significant business impact but there are many misconceptions about “Agile versus Waterfall” that can be very misleading.

One of the big misconceptions is that “Agile” and “Waterfall” are often thought of as binary and mutually-exclusive alternatives. The result of that misconception is that businesses sometimes force-fit their business and projects to one of those extremes when the right solution is to go in the other direction and fit the approach to the project. Sometimes projects require a blend of both approaches – it takes more skill to do that, but it definitely can be done.

Since this is such a critical decision that has such a big impact, I think it’s very important to have a clear understanding of what we mean when we talk about “Agile versus Waterfall”. In this video, I want to try to help you see these two approaches in a fresh new perspective to get the best of both of these two worlds. You can view the video here (it is about 10 minutes long):

http://youtu.be/pp8-jFpa-G4

What is an Enterprise-level Agile Coach?

When people use the term “Agile Coach” it is often not exactly clear what they mean. Most often, what they’re talking about is what I would call a team-level Agile Coach. That is someone who works at a tactical level with individual members of an Agile team to help them become more proficient in executing an Agile development process such as Scrum. There is very little standardization or certification for what it takes to become an “Agile Coach” at that level and almost anyone could claim to be an “Agile Coach”.

Beyond that; however, there is a different kind of Agile coaching role at an enterprise-level that needs to be better-defined and differentiated from a normal team-level “Agile Coach” role. The enterprise-level role is someone who works at a more strategic level to integrate an Agile development process with a company’s business. That role is not well-defined at all and the difference between the team-level role and the enterprise-level role is also not clearly differentiated. It is assumed that someone who has “Agile Coach” on his/her resume can do all of that and I don’t believe that is necessarily correct.

What often happens in applying Agile at an enterprise level is that an “Agile Coach” attempts to plan and organize an enterprise-level agile transformation. However, that person is probably only trained in Agile from a team-level development process perspective and makes the assumption that whatever is good for the development process must be good for the business as a whole. They also may assume that it is a binary and mutually-exclusive decision to be either “Agile” or “Waterfall” and attempt to force-fit the entire company into an Agile model when the right solution is to fit the approach to the company’s business. I don’t believe that either of those assumptions is necessarily correct.

The problem is this – Agile works very well in companies that are in the primary business of developing products (particularly software products – Intuit is an example that develops TurboTax, Quicken, and QuickBooks). In those companies, there is a strong and natural alignment between an Agile development process and the overall business goals of the company and it is very easy to apply an Agile development process in that environment. It is much more difficult to apply an Agile development process in a company who is not in the primary business of developing products and is in some other kind of business where the relationship of an Agile development process to the company’s overall business strategy is much more indirect.

In companies that are not in the primary business of developing products, you can’t just force the company to be “Agile” in order to make the company more amenable to an Agile development process. The company’s overall culture and business strategy needs to be optimized around whatever the critical success factors are for the business that they are in. For example, if a company is in a business that requires operational excellence, it needs to focus its overall culture and business strategy primarily on efficiency of operations and reducing costs and that doesn’t necessarily align with just becoming more “Agile”. In that kind of environment, you have to develop a strategy that considers both the company’s business strategy and the requirements of an Agile development process to develop a well-integrated approach. The implementation of that strategy often requires fitting the approach to the company’s business environment rather than trying to force-fit the company to some kind of overall Agile approach.

The approach that you might wind up with in that kind of environment also could be a blend of Agile and traditional plan-driven management principles and practices blended together in the right proportions to fit the situation. That is a lot more difficult thing to do and requires a lot more skill than a typical team-level Agile coach would normally have. It requires an understanding of:

  • Agile principles and practices as well as
  • Traditional project management principles and practices

and a deeper understanding of the principles behind both of them (not just the mechanics) to know how to blend them together as necessary to fit a given situation. Beyond that; however, it also requires the ability to look at a very complex, broad-based, enterprise-level business from both a more strategic high-level business management perspective as well as a more tactical product development process perspective to develop a strategy for integrating the two.

What often seems to happen is someone who is trained in “Agile” from a development process perspective attempts to steer the company in the right direction and that person typically doesn’t have the breadth of business management experience and agile development process experience to know how to successfully integrate the two. Is it any wonder why some of these “Agile transformations” are not successful?

I’ve developed some on-line training that should be helpful to people who want to understand this better:

  • Agile Project Management Overview for Project Managers – addresses this from a project management perspective to help project managers see Agile and traditional project management principles and practices as complementary rather than competitive and to learn how to blend the two together to fit any given situation.
  • Agile Project Management Overview for Executives – addresses this from a business management perspective and provides some essential principles and guidelines of how to successfully develop a well-integrated enterprise-level approach for any business.