Guest post by Chuck Cobb, Breakthrough Solutions/The Business Excellence Group

The concept of agile project management is very rapidly evolving and will have a significant impact on the project management profession, causing us to rethink many things we have taken for granted about what “project management” is for a long time.  However, we are in the very early stages of that transformation and there is a lot of confusion that exists in today’s world between the agile and traditional plan-driven project management (aka “waterfall”) communities. Many people see them as competitive and mutually-exclusive alternatives.  Some of the factors that contribute to this confusion are:

  • Many stereotypes and misconceptions exist about both agile and traditional plan-driven project management
  • Agile and traditional plan-driven project management principles and practices have been treated as separate and independent domains of knowledge with very little or no integration between the two
  • Agile and “waterfall” have been treated as binary, mutually-exclusive alternatives and many people make the mistake of force-fitting a project to one of those extremes

It’s no wonder that project managers and others might be confused by all of this!

A large portion of closing the gap that exists between the agile and traditional plan-driven project management communities can be attributed to a mindset change that includes:

1. Getting past a number of stereotypes and misconceptions that exist about both agile and traditional project management

2. Broadening our thinking about what “project management” is

Here are a few examples of the most popular stereotypes and misconceptions that exist about project managers:

1. Project managers are very “Command-and-Control” oriented.”

There is probably some reality behind this stereotype. Project managers are noted for getting results and sometimes that means being assertive and somewhat directive to set goals and manage the performance of project teams; sometimes that’s necessary.  Many times that behavior is expected of a project manager by the businesses in which they operate.  For example, if a project team is underperforming, the project manager is the one often held responsible and is expected to take corrective action to get the project on track.

2. Project managers are rigid and inflexible.

This stereotype also has some reality behind it, too. For many years, project managers have been held accountable for managing the costs and schedules of projects; and we all know that in order to meet cost and schedule goals, you have to control the scope of the project. That, in turn, requires a disciplined approach to managing change where change become the exception rather than the norm.

3. Project managers only know how to manage by the “waterfall” methodology.

The emphasis on managing costs and schedules for a long time has required accurately defining the requirements upfront, which leads to extensive use of “waterfall-style” methodologies that are based on trying to define project requirements in detail upfront before the project starts.  The emphasis on cost and schedule management is a significant reason why that approach continues to be used today.

4. Project managers are just not adaptive and cannot adapt to an agile environment.

I don’t believe that stereotype is correct, but it does require a significant shift in thinking for a project manager to make that adaptation. A good project manager knows that you have to adapt the project management approach to fit the problem rather than force-fit every problem or project to a single approach.

It should be apparent from all of these stereotypes that many of these behaviors are a function of the environment in which project managers operate, and are influenced by the expectations that businesses have of project managers. Creating a broader image of what project management is will also require influencing the environment and expectations on project managers.

Here are a few examples of the most popular stereotypes and misconceptions that exist about agile:

1. Agile projects are totally unplanned.

There is actually a lot of planning going on — It’s just a different kind of “just-in-time” planning that is more spread out through the project rather than being done heavily or totally upfront.  However, doing upfront planning is definitely not inconsistent with an agile approach. As an example, I was asked to rescue an agile project where, two years into the project, the project had no end in sight, and senior management had lost confidence that it would ever produce results. When we re-planned the project, we discovered that the scope of the effort was just too large to be done by a single agile team in any reasonable amount of time. If more upfront planning had been done, this problem would have been discovered much earlier.

2. Agile projects do not use any process and are totally uncontrolled.

That stereotype is also not accurate. Most agile projects use Scrum, which is a very well-defined process.  It’s a different kind of process – it is much more empirical and adaptive rather than rigid and prescriptive, but it is a well-defined process. It is also not difficult to apply whatever level of control you want to an agile project.  As an example, a few years ago I managed a large U.S. federal government project for the Federal Aviation Administration. We were able to create a hybrid model with a sufficient level of control to meet government contracting requirements, but at the same time provide a sufficient level of flexibility to further define detailed requirements with an agile development process.

3. There is no project management required for an agile project.

Although there may be no one with the title of “project manager,” in an agile project at the team level, there is plenty of project management going on.  It’s just a different kind of project management and the project management functions are distributed over a number of different people on the team rather than being held by one particular individual called a “project manager.”

  • The product owner in a Scrum project performs many project management functions by setting the direction and priorities for the project and making decisions as the project progresses; he or she is responsible overall for the success or failure of the project from a business perspective.
  • The ScrumMaster performs some project management functions by facilitating the team and the process, and is also responsible for removing obstacles that impede the team’s performance.
  • Everyone on an agile team performs some very basic project management functions in planning, estimating, and managing their own work, as well as tracking and reporting progress. Each member of the team as a whole must also coordinate and integrate all the activities of the team.

4. Documented requirements are not consistent with agile. Documentation is still useful in an agile project where it adds value.  Of course, documentation should not be done for the sake of creating documentation; however, there are many situations where it makes sense to document requirements in an online agile project management tool using a simple user story format as the project progresses.

In “The Next Generation of Project Management,” we need to:

  • Broaden our thinking about what “project management” is and think of it as a function, not a discrete role associated with someone called a “project manager,”
  • Develop a fully integrated agile project management approach that blends both agile and traditional plan-driven approaches in the right proportions to fit a given situation when necessary, and
  • View agile and traditional plan-driven project management approaches as complementary to each other rather than competitive

This is a significant challenge and will require a lot of new thinking, but it can be done.

It feels very similar to an evolution that took place when I worked in the quality management profession in the early 1990s. Up until that time, the primary emphasis in quality management had been on ‘quality control’ and inspection; the image of a ‘quality manager’ was heavily based on managing those functions.

  • The predominant quality management approach at that time was based on inspecting products before they were released from production prior to shipping to the customer and rejecting any that didn’t meet quality standards. It’s easy to see how that approach was inefficient because it resulted in a lot of unnecessary rework to correct problems after the fact and it also wasn’t that effective because any inspection approach is based on sampling – and it’s impractical to do a 100% sample. For that reason, this approach can result in a very mediocre level of quality.
  • A far better approach was to go upstream in the process and eliminate defects at the source by designing the process to be inherently more reliable and free of defects. That didn’t mean that the prior emphasis on quality control and inspection was obsolete and eliminated; it was just not the only way to manage quality, and wasn’t the most effective approach in all situations.
  • At the same time, “quality” took on a much broader meaning. It was no longer sufficient to produce products that were free of defects; producing products that were free of defects became just ‘table stakes’ to play in the game.  To be successful, companies really needed to go beyond that and produce products that really delighted their customers.

That was a gut-wrenching change for many in the quality management profession. Instead of being in control of quality and being the gatekeeper with the inspection process, a good quality manager needed to become more of a coach and a consultant to influence others to build quality into the way they did their work.  This changed the nature of the work dramatically for many in the quality management profession and eliminated a number of traditional quality management roles that were based primarily on the old quality control-and-inspection approach.  The similarity to the changes going on in the project management profession should be apparent:

  • Project managers needed to recognize that simply controlling the costs and schedules of a project was no longer sufficient; the project had to be successful from the perspective of producing value for the customer as well.
  • To be successful in more uncertain environments and focus on producing value, project managers need to be able to take an adaptive approach that is appropriate to the level of uncertainty in the project.
  • Finally, they need to give up some of the control that has become associated with the project management profession – in some cases, they may need to become more of a coach and a consultant to influence others rather than being in absolute control of a project.

This can dramatically change the role of a project manager and, in some situations, the role of a project manager as we’ve known it may no longer exist.  For example, at a team level in an agile project, you probably won’t find anyone with a title of “project manager” because the project management functions have been absorbed into other roles and are done very differently.  That doesn’t mean that project management is no longer important, but it may cause us to dramatically rethink what “project management” is in a much broader context than the way we may have thought about it in the past.[1]

About Chuck

Chuck Cobb is an Adjunct Professor at Boston University where he will be teaching a brand new, graduate-level course on agile project management. He is passionate about helping close the gap between the agile and traditional project management communities. To that end,

  • He has published two books on agile project management (a third book entitled “The Project Manager’s Guide to Mastering Agile” will be published in early 2015 by Wiley Publishing)
  • He has written over 50 articles on his blog site and has recently developed an online training course to help project managers learn how to develop an adaptive approach to project management that blends agile and traditional project management principles and practices in the right proportions to fit any situation

Chuck has worked with VersionOne for a number of years and has devoted a portion of his new book to using the VersionOne agile project management tool as an example of the importance of using tools in an enterprise-level agile project management strategy.

[1] Cobb, Charles, “The Project Manager’s Guide to Mastering Agile – Principles and Practices for an Adaptive Approach, Wiley Publishing, 2015

Join the Discussion

    4 + 3 =