Category Archives: Agile Project Management

New Course – What Is the Future of Agile Project Management?

I’ve just launched a new course entitled “What Is the Future of Agile Project Management?”  This is a very confusing topic for many project managers because the role of an Agile Project Manager in the real-world is not well-defined:

What Is the Future of Agile Project Management?

I frequently see questions from project managers asking like:

  • What certification should I get?
  • Should I become a Scrum Master?

It’s understandable that there is a lot of confusion about this because there is no defined role for a project manager in a typical Agile project at the team level.  There are roles that a project manager can play in an Agile but:

  • It may not be the typical, team-level project manager role,
  • It does require a big shift in thinking for a project manager to adapt to an agile environment, and
  • It’s a very different kind of “project management” that emphasizes creativity and innovation to maximize the value of the solution as well as some level of planning and control to achieve predictability

To fill this role, an Agile Project Manager has to learn how to blend Agile and traditional plan-driven project management principles and practices in the right proportions to fit any given situation and that is exactly what my training curriculum  is designed to do.

This particular course is designed to help project managers understand the impact of Agile and Lean on the Project Management profession and on their own career paths and to develop a strategy to adapt to this new environment.   The course is a little over an hour long and includes material on the impact of Agile and Lean on the future of project management as well as some real-world scenarios where an Agile Project Manager can provide a lot of value in an Agile/Scrum environment.  It is designed to help project managers reinvigorate their careers into a very high-impact Agile Project Management role.

For a limited amount of time, I am offering this course for only $5 to anyone who would like to take the course and provide feedback.  You can click on the link below to take advantage of this offer:

What Is the Future of Agile Project Management?

Why Should Project Managers Care About Agile? What Is the Impact?

Why Should Project Managers Care About Agile? There are many people in the project management profession who are in “denial” about the influence of Agile. Here are some of the common reasons for a project manager might ignore the influence of Agile:

  • Many people seem to think that there is a binary and mutually-exclusive choice between an “Agile” approach and a “Waterfall” approach and “Agile” really only applies to software
  • Some project managers don’t see Agile as a legitimate form of project management although PMI has slowly come around to recognizing that with PMBOK v6

The truth is that Agile is changing the very nature of “project management” and, as a result, “project management is taking on a much broader meaning.

Why Should Project Managers Care About Agile?

A Modern View of What “Project Management” Is

The table below shows how the very nature of project management is changing as a result of Agile:

Views of “Project Management”
Traditional, Narrow View Modern, Broader View
Traditional “Project Management” is heavily associated with planning and control The competitive environment today requires an emphasis on creativity and innovation in addition to planning and control.

Simply planning and controlling a project is no longer sufficient. Can you imagine a leading-edge, high-technology product like a new iPhone being developed with a traditional, plan-driven project management approach?

Success in project management is defined by delivering well-defined project requirements within an approved budgeted cost and schedule Today’s world has a much higher level of uncertainty which makes it difficult to always start a project with well-defined requirements.

Business value is what is important and costs and schedules are only one component of business value. There have been many projects that met their cost and schedule goals but failed to deliver an appropriate level of business value.

Project management is only done by someone who has the title of “Project Manager” In an Agile environment, there is actually a lot of “project management” going on although you may not find anyone with the title of “Project Manager”.

The project management functions that might normally be performed by someone with the title of “Project Manager” have been distributed among all the members of the team and its a different kind of “project management” with an emphasis on producing business value in an uncertain environment.

Many project managers have difficulty accepting this kind of change because it fundamentally changes the definition of what “project management” is which can be very unsettling. They want to hold on to traditional notions of what “project management” is that haven’t changed significantly since “project management” was first formalized as a profession in the 1950’s and 1960’s, but project managers who ignore this change run the risk of being left behind.   In the not-too-distant future, project managers who only know how to do a traditional, plan-driven approach to project management may have a limited future in a number of industries and application areas such as software development.

Similarity to Quality Management

I worked in the Quality Management with Motorola in the early 1990’s and that profession went through a similar gut-wrenching change at that time. The old approach to quality management was heavily-based on inspection and control.

  • Lots of QC inspectors were employed to find defects in products before they shipped and
  • The role of a Quality Manager was to control the quality of products that were shipped and enforce quality standards.

Companies began to realize that approach was very inefficient and resulted in a lot of unnecessary scrap and rework of defective products. A much more proactive approach was needed that involved eliminating defects at the source by designing processes that were inherently reliable.

Implementing that kind of change required a very different approach to quality management…instead of an emphasis on control and inspection, it required coaching and mentoring people to integrate an emphasis on quality into any job and process that had anything to do with producing products.  The results were enormously successful, it resulted in levels of quality that were unattainable with a typical quality control approach, and that was how Six Sigma was originally conceived.

In those days, my manager used to tell me that “Our job as a Quality Manager is to teach, coach, and audit” in that order. In other words, you had to be a missionary to spread an emphasis on producing quality throughout the whole company rather than attempting to be totally responsible for “quality” yourself.  That’s exactly what is happening today with the project management profession – instead of a Project Manager attempting to be in control of all of the project deliverables, he/she needs to teach and coach others to take some level of basic project management responsibility including functions such as:

  • Planning and estimating their own work,
  • Building quality into the product rather than relying on someone else to find defects later,
  • Integrating with the rest of the team as a whole to produce an overall solution, and
  • Reporting on progress

It’s essentially a distributed approach to project management that engages everyone in the project management process instead of one Project Manager attempting to control everything.  In a very uncertain and dynamic environment, that has got to be a much more flexible and adaptive approach.

Why Should Project Managers Care About Agile?

The impact of Agile on the role of many project managers is likely to be significant. On small, single-team Agile projects, you may not find someone called a “Project Manager” at all; however, there certainly is a need for someone to coach and mentor the team on Agile Project Management practices. There is also a need for project managers on larger and more complex enterprise-level projects but even at that level, some understanding of Agile is essential. This “raises the bar” for project managers significantly. It requires project managers to develop a fresh new perspective to see Agile and traditional, plan-driven project management approaches as complementary to each other rather than competitive and to learn how to blend the two approaches in whatever proportions are needed to fit any situation.

What’s Needed to Adapt to This Change?

I’ve given a lot of thought to this problem and I am very passionate about helping project managers adapt to this change. Here are a number of articles I’ve written on this subject that should help project managers understand the impact of this change and begin adapting to it:

 

Articles on Agile Project Management
Article Synopsis
What Does Physics Teach Us About Agile Project Management Training? There’s a lot of similarity between the way that the science of physics has evolved and how project management has evolved:

  • For many years until the late 1800’s and early 1900’s, physics was based on what is called “Classical Physics”
  • “By the end of the nineteenth century, most physicists were feeling quite smug. They seemed to have theories in place that would explain all physical phenomena.”
  • “Twenty-five years later, this complacency had been completely destroyed by the invention of three entirely new theories: special relativity, general relativity, and quantum mechanics.”

In other words, the universe turned out to be much more complex, more dynamic, and less predictable than people thought it was. Isn’t that exactly what has happened with the project management profession?

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

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

With the introduction of PMBOK v6 and the new PMI Agile Practice Guide, PMI has taken a major step towards recognizing that there is a need to integrate an Agile approach with a traditional plan-driven approach to project management in the right proportions to fit a given situation.

Up until this time, “Agile” and traditional, plan-driven project management have been treated as separate and independent domains of knowledge with little or no integration between the two.

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

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

With the introduction of PMBOK v6 and the new PMI Agile Practice Guide, PMI has taken a major step towards recognizing that there is a need to integrate an Agile approach with a traditional plan-driven approach to project management in the right proportions to fit a given situation.

The PMP certification, as we have known it for a long time has been the mark of a very professional and well-qualified project manager; however, up until March 2018, the PMP exam has been totally based on traditional plan-drive project management.

PMI has recognized this limitation and in March of 2018 will begin to incorporate more Agile content in the PMP exam.

Is Project Management Obsolete? What Do You Think? Talks about the need to rethink what project management is if it is to thrive in the future.
Learn the Truth About Agile versus Waterfall Helps to overcome some misconceptions about Agile and Waterfall to see these two approaches in a fresh new light as complementary rather than competitive.

What Does Physics Teach Us About Agile Project Management Training?

What does Physics teach us about Agile Project Management Training?   We can learn a lot from how the science of physics has evolved and how universities have developed Physics curricula.  I think there are a number of interesting similarities to an Agile Project Management training curriculum.

Agile Project Management Training

What is the Similarity of Agile Project Management Training To Physics?

For many years until the late 1800’s and early 1900’s, physics was based on what is called “Classical Physics”.

What is Classical Physics?

“Classical physics is the physics of everyday phenomena of nature, those we can observe with our unaided senses. It deals primarily with mass, force and motion. While its roots go back to the earliest times, to the Ancient Greeks such as Aristotle and Archimedes, it later developed into a cohesive system with the contributions of Galileo, Kepler and Newton. Classical physics achieved phenomental success, as the Calculus of Newton and Leibniz gave it the tools to tackle even even problems not imagined by its pioneers.”

“Around 1900, give or take a decade, surprising new experimental evidence, primarily about atoms and molecules, showed us that these small-scale phenomena behave in ways not anticipated by classical theory. This ushered in a new era called “modern” physics. New laws and methodology were developed to deal with the rapidly expanding experimental evidence. Relativity and quantum mechanics added new tools to the study of nature. These did not make classical physics “wrong”, for the old laws were working just as they always had, within their limited scope—which was the study of large objects (not atomic scale ones) moving relatively slowly (not near the speed of light). “

“So classical physics is still the starting point for learning about physics, and constitutes the bulk of the material in most introductory textbooks. It is the theory underlying the natural processes we observe everyday. It is the key to understanding the motion of pulleys, machines, projectiles and planets. It helps us understand geology, chemistry, astronomy, weather, tides and other natural phenomena”

Simanek, Donald E., What’s Physics All About?, https://www.lhup.edu/~dsimanek/ideas/allabout.htm

What Happened to Cause People to Rethink Classical Physics?

That notion of physics that was intended to define how the entire universe worked held together for a long time; however, serious weaknesses began to appear around the early 1900’s:

“By the end of the nineteenth century, most physicists were feeling quite smug. They seemed to have theories in place that would explain all physical phenomena. There was clearly a lot of cleaning up to do, but it looked like a fairly mechanical job: turn the crank on the calculator until the results come out. Apart from a few niggling problems like those lines in the light emitted by gas discharges, and the apparent dependence of the mass of high-speed electrons on their velocity”

“Twenty-five years later, this complacency had been completely destroyed by the invention of three entirely new theories: special relativity, general relativity, and quantum mechanics. The outstanding figure of this period was Albert Einstein. His name became a household word for his development, virtually single-handedly, of the theory of relativity, and he made a major contribution to the development of quantum mechanics in his explanation of the photoelectric effect. “

Slavin, Alan J., “A Brief History and Philosophy of Physics”, https://www.trentu.ca/physics/history_895.html

How is This Transformation Related to Project Management?

Classical Physics is analogous to traditional, plan-driven project management. Similar to the laws of classical physics,

  • The traditional, plan-driven project management approach has been widely accepted as the only way to do project management for a long time. and,
  • The way traditional, plan-driven project management is done hasn’t changed significantly since the 1950’s and 1960’s. It assumes a very predictable view of the world where it was possible to completely define a project plan with a fairly high level of certainty prior to the start of a project

That is similar to classical physicists who believed for a long time that a model of the universe could be completely predicted based on some relatively simple and well-defined laws of classical physics. In recent years; however, it is apparent that we are in a much more dynamic and more complex universe with much higher levels of uncertainty where that traditional, plan-driven approach to project management no longer works well at all.

What Can We Learn from This Similarity?

Traditional, plan-driven project management (just like Classical Physics) will never be totally obsolete and will continue to be a foundation for many areas of project management:

“…classical physics retains considerable utility as an excellent approximation in most situations of practical interest. Neither relativity nor quantum theory is required to build bridges or design cellphone antennas.”

The never-ending conundrums of classical physics, https://www.trentu.ca/physics/history_895.html

However, it is important to recognize and not ignore the limitations that are inherent in a traditional, plan-driven project management approach. Experienced physicists have learned to recognize the limitations of classical physics that it only works reliably in a certain range of situations as shown in the figure below:

modern-physics

“Classical Physics is usually concerned with everyday conditions: speeds much lower than the speed of light, and sizes much greater than that of atoms. Modern physics is usually concerned with high velocities and small distances.”

https://en.wikipedia.org/wiki/Modern_physics

Similarly, project managers also need to recognize that a traditional, plan-driven approach to project management only works reliably in a limited set of situations. In the project management world, this can be expressed with the Stacey Complexity Model:

stacey-complexity-model

In this model, there are two primary dimensions – one is requirements complexity and the other is technology complexity.

  • Traditional, plan-driven project management still works in areas of low complexity such as some construction projects but even in some of those areas, project managers have recognized a need for a somewhat more adaptive approach
  • As you get further out on either complexity axis, there is typically a need for more of an adaptive Agile approach that is better suited for dealing with uncertainty but this is not a binary and mutually-exclusive proposition. There is a need to blend both approaches in the right proportions to fit the situation

What’s the Impact on Project Managers?

Just as new theories about Physics have significantly extended the notion of what “Physics” is beyond the traditional world of Classical Physics, Agile will have a similar impact on project managers.  The way this will probably evolve is very likely similar to the way that Physics has evolved:

  • In today’s world, there are people who specialize in Classical Physics and people who specialize in the more esoteric areas of Modern Physics; however, neither one of those areas can ignore the existence of the other area and a truly broad-based Physicist has a fairly solid knowledge of both of those areas
  • I believe that a similar thing is likely to happen in Project Management.  There will be project managers who continue to specialize in a traditional plan-driven approach to project management and project managers who specialize in Agile; however, just as in Physics,  neither one of those areas can ignore the existence of the other area and a truly broad-based Agile Project Manager has a solid knowledge of both of those areas

An Agile Project Manager is not a project manager who only works in an Agile environment.  It is someone who has a broad-based knowledge of both Agile and traditional plan-driven project management and knows how to blend those two approaches in the right proportions to fit any given situation.  The online Agile Project Management Training in The Agile Project Management Academy is designed around exactly this need.

 

Is Project Management Obsolete – What Do You Think?

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

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

Is Project Management Obsolete

Examples of Companies and Professions Reinventing Themselves

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

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

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

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

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

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

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

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

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

How Does This Relate to Project Management?

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

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

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

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

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

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

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

In today’s world:

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

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

  • “A good ‘cook’ may have the ability to create some very good meals, but those dishes may be limited to a repertoire of standard dishes, and his/her knowledge of how to prepare those meals may be primarily based on following some predefined recipes out of a cookbook.”

  • “A ‘chef’, on the other hand, typically has a far greater ability to prepare a much broader range of more sophisticated dishes using much more exotic ingredients in some cases. His/her knowledge of how to prepare those meals is not limited to predefined recipes, and in many cases, a chef will create entirely new and innovative recipes for a given situation. The best chefs are not limited to a single cuisine and are capable of combining dishes from entirely different kinds of cuisine.” (Cobb – The Project Manager’s Guide to Mastering Agile)

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

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

What Has Been Done to Transform the Project Management Profession?

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

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

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

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

There are at least two major problems with that definition:

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

Summary – Is Project Management Obsolete

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

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

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

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

What is Project Management? Is it Mutually-exclusive with Being Agile?

I recently participated in an online discussion where someone made the statement that “Project Management and Scrum have nothing to do with each other. In fact, they mutually exclude each other.” I want to share my response with you because I think there is an important issue about rethinking “What is Project Management?”

What is Project Management? – A Narrow View

That view of project management is based on a very popular and widely-held stereotype about what “project management” is:

  • “Project management” is something that is only done by a single person called a “Project Manager”
  • There is only one way to do “project management” and that is using a traditional plan-driven methodology (what many people loosely call “Waterfall”)
  • “Project management” is completely incompatible with an Agile approach because an Agile approach must be dynamic and adaptive and project management emphasizes control and is inflexible

That’s a very narrow view of what “project management” is; however, that view is widely-held by a lot of people and the project management community has not done enough to change that perception:

  • PMI still treats Agile and traditional plan-driven project management as separate and independent domains of knowledge with little or no integration between the two
  • Many project managers are heavily indoctrinated in a traditional plan-driven project management approach and see that as the only way to do project management

If you look at the official PMBOK definition of “project management”, it is very consistent with that narrow view of what project management is:

“The application of knowledge, skills, tools and techniques to the project activities to meet project requirements” – (PMBOK version 5)

That definition implies that “project management” is mainly concerned with planning, organizing, and managing project activities to meet defined requirements. Which is exactly how a traditional plan-driven project works but it is not consistent with how an Agile/Scrum project works.

What is Project Management? – A Broader View

If you look at how an Agile/Scrum project works, there is actually a lot of “project management” going on but many people will not recognize it as “project management” because it doesn’t fit with the traditional stereotype of what “project management” is:

  • In an Agile/Scrum project you may not find anyone at the team level with the title of “Project Manager”
  • The project management functions that would normally be done by a single person called a “Project Manager” are distributed among all the members of the Agile team. For example:
    • Developers – All members of the project team are expected to take responsibility for planning and completing the tasks that they are responsible for to meet commitments that they have made. They are also expected to report progress and coordinate their work with other members of the team as necessary.
    • Scrum Master – The Scrum Master is expected to facilitate team meetings and take action to remove any obstacles if necessary
    • Product Owner – The Product Owner is expected to make any decisions or tradeoffs that might be needed to meet the project goals

    Those are all functions that would normally be performed by a project manager if there was one; they are simply distributed across a number of roles rather than being performed by a single person called a “Project Manager”.

  • It doesn’t use a traditional plan-driven approach to project management – the requirements may not be well-defined at the beginning of the project and it uses a more adaptive approach to further refine the requirements as the project is in progress

Does that mean that there is no “project management” going on?  I don’t think so – it’s just a different kind of “project management” that doesn’t fit the typical narrow stereotype that many people have of what “project management” is.

Here’s what I think a broader definition of “project management might look like:

“Project Management is the application of knowledge, skills, tools, and techniques to accomplish a meaningful objective and maximize the value that the project produces.”

What’s Different?

Here are a couple of key areas of difference that I believe are important:

  • My definition of project management doesn’t say anything about defined requirements.  It is based on a broader idea that a project manager should be able to be given a broadly-defined business objective and figure out what is needed to achieve that objective
  • The goal of a project manager should also be to produce business value, not just meet cost and schedule goals for delivering defined requirements.  There have been many traditional plan-driven projects that have met their cost and schedule goals but failed to deliver business value and they were still considered successful from a project management perspective

Why is this Important?

Many of the traditional notions of what “project management” is have their roots in the 1950’s and 1960’s and the fundamental nature of what “project management” is has not changed significantly since that time. We live in a different world today from what existed in the 1950’s and 1960’s:

  • Technology is rapidly changing
  • Solutions are much more complex
  • There is a much higher level of uncertainty in many projects
  • Time-to-market is extremely critical to keep pace with competition

Attempting to force-fit all projects to a traditional plan-driven model that hasn’t changed significantly since the 1950’s and 1960’s is probably not going to result in an optimal solution.  You have to fit the project management approach to the nature of the problem and that calls for a broader range of project management approaches not limited to traditional plan-driven project management.

The key message is that you need to fit the project management approach to the nature of the problem rather than force-fitting all projects to a single project management approach.

An Integrated and Dynamic Approach to Project Management

I think of this as an “integrated and dynamic” approach to project management:

  • It’s integrated because project management is fully integrated into the way the team works rather than being done by a single person called a “Project Manager”
  • It’s dynamic because the nature of the project management approach isn’t limited to a traditional plan-driven approach to project management.  It is expected that the project management approach will be adapted to fit the nature of the situation

I think you can see that if your objective is control, a traditional plan-driven approach to project management of putting one person called a project manager in control of a project might be a good approach; however, an emphasis on control can be inflexible and doesn’t work well in an uncertain environment that requires a more adaptive approach. We need to adapt the approach to fit the nature of the project and the level of uncertainty in the project is a major factor in choosing the right approach.

Transforming the Project Management Profession

Dealing with this challenge really requires a major transformation of the project management profession, in my opinion.

What is Project Management?

Here are some fundamental things that need to be done:

  1. We need to think of “project management” in broader terms than thinking that traditional plan-driven project management is the only way to do project management
  2. Project managers need to be trained in how to blend Agile and traditional plan-driven project management principles and practices in the right proportions to fit any given situation
  3. We need to recognize that “project management” is a function, not a title, and the function of “project management” is not always exclusively performed by someone called a “Project Manager”

I’ve Been Here Before

There is a feeling of deja vu about this to me.  I’ve been here before.  In the early 1990’s, I worked in the Quality Management profession at Motorola.  Motorola was a leader at that time in developing a new approach to quality management.  The old approach to “quality management” was something like this:

  • There was a heavy emphasis on control.  Someone called a “Quality Manager” had responsibility for controlling the quality of the products being built.
  • The quality management approach relied heavily on  inspectors who enforced standards of quality through inspection of products before they shipped

The flaws in that approach should be obvious:

  • Relying heavily on inspection to find defects can result in a significant amount of rejects and rework – a far better approach is to go upstream in the process, remove the source of defects, and make the process that produces the products inherently reliable
  • Putting responsibility for quality in the hands of a single person or organization makes the employees who are responsible for producing the product feel that “quality is someone else’s responsibility”.  A far better approach is to engage everyone in the quality management functions so that everyone involved in producing a product feels that they are directly responsible for the quality of the products they produce

A similar thing could be said about project management today – putting all project management responsibility in the hands of someone called a “Project Manager” makes the workers feel like “project management” is someone else’s responsibility.  A far better approach in a complex and uncertain environment is to engage everyone in “project management” so that it is a shared responsibility among everyone on the team to make the project successful.

What are the Most Practical Ways to Do Project Planning?

I recently participated in an online discussion in response to a question that was asked on “What are the most practical ways to do project planning?” It’s a critical issue and it comes up a lot so I thought I would share some thoughts on this subject.

Factors to Consider

In my opinion, there are two very significant factors in determining what planning approach would make the most sense for a particular project:

  1. Uncertainty – The level of uncertainty in the project is probably the most important factor.  If there is a high level of uncertainty that cannot easily be resolved, it would probably be foolish to try to develop a highly-detailed, plan-driven approach.  An example would be attempting to find a cure for cancer.  It would probably be foolish to try to develop a detailed plan for that effort, there’s just way too much uncertainty.That doesn’t mean that you wouldn’t do any planning at all.  You would take stock of what you know and don’t know and try to develop at least a cursory plan based on that information and then continually revise the plan based on what you learn as the project is in progress.
  2. Customer Relationship – The second major factor is the relationship with the customer.   If you have a contractual relationship with the customer where the customer is expecting a firm set of deliverables for a given schedule and cost, you might be forced into a planning model to try to effectively manage and satisfy those customer expectations.  If there is more of a collaborative relationship with the customer, you probably have a lot more ability to optimize the approach based on the level of uncertainty in the project.

Planning Quadrants

Obviously, there may be a conflict between these two factors.  I’ve created a diagram below to show some of the possible combinations of these two factors:

What are the most practical ways to do project planning?

Lets look at each of these quadrants individually:

  1. Low Uncertainty, Contractual Relationship – This is the area that most project managers are most familiar with and it is the area that is most well-suited for a traditional plan-driven project management model.  In this area, the level of uncertainty may be low enough to permit developing a detailed plan that is consistent with managing customer expectations in a contractual relationship model.
  2. Low Uncertainty, Collaborative Relationship – If the level of uncertainty associated with a project is low, you might develop a more collaborative relationship with the customer but that might not be the most efficient way to do the project.  If the level of uncertainty is truly low and it is relatively easy to define the project requirements upfront, it may not make too much sense to engage the customer too heavily in a collaborative relationship to further define detailed direction for the project as it is in progress.
  3. High Uncertainty, Collaborative Relationship – This is the area where an Agile approach makes sense but the success of that effort will generally depend on a collaborative relationship with the customer to make it work.  In this area, instead of trying to develop a highly-detailed upfront plan prior to starting the project, you would probably:
    • Reach agreement with the customer on at least a vision for the project and at least some higher level objectives and requirements that the project must meet, and
    • Then further elaborate those requirements and the plan for meeting them as the project was in progress

    It’s easy to see how this kind of planning model may not work well unless there’s a collaborative spirit of trust and partnership with the customer since:

    • It may be almost impossible to accurately define the costs and schedule for completing the project prior to starting the effort; and
    • Further defining the plan as the project is in progress requires a close working relationship with the customer.
  4. High Uncertainty, Contractual Relationship – This area is the quadrant that is likely to be most problematic:
    • Attempting to do an Agile project with highly uncertain requirements without a collaborative relationship with the customer is not likely to work very well:
      • The customer may not be committed to actively engage in the project as it is in progress to help elaborate and resolve questions related to the requirements; and,
      • As a result, the project may either get stalled or go off in the wrong direction
    • Attempting to apply a contractual, plan-driven approach in this kind of environment is also likely to be problematic. There would likely be a very high risk associated with trying to develop a firm, plan-driven contractual relationship based on highly uncertain requirements. What is likely to happen is:
      • The project meets the defined requirements but the defined requirements were wrong, or
      • There are so many changes as the project is in progress that the scope of the project winds up being completely different from what the customer was expecting

    It’s easy to see how either of these scenarios might present a very high risk.

Of course, this is somewhat of an over-simplification and all projects don’t fall very neatly into one of these quadrants.  There is a very broad range of scenarios in the middle of this diagram that call for some kind of hybrid approach.

What are the Most Practical Ways to Do Project Planning?

There are a number of conclusions that I think we can draw from an from understanding of this model:

  1. There is not just one way to do project planning – Project Managers who have been heavily indoctrinated in a traditional, plan-driven model and attempt to force-fit all projects to that kind of planning model are likely to not have optimal results
  2. This is not a simple binary and mutually-exclusive choice between an Agile and traditional plan-driven planning model; it is much more complicated than that.  There’s a whole spectrum of different possible scenarios and it is a multi-dimensional problem
  3. The right approach is to fit the planning model to the nature of the problem based on the level of uncertainty and the relationship with the customer.  Attempting to use a single “one size fits all” planning model for all projects is not likely to work very well.

This creates a big challenge for project managers to learn how to blend an Agile and traditional plan-driven approach in the right proportions to fit a given situation.  And, that’s not an easy thing to do – PMI still treats these two areas as separate and independent domains of knowledge with little or no integration between the two.  This is exactly the challenge that my Agile Project Management training is designed to address.

Is Agile and Scrum Anti-Engineering?

I recently participated in an online discussion on the topic of “Is Agile and Scrum Anti-Engineering?”.  This question seems to be based on a number of popular stereotypes that people have about “Agile” and engineering design practices.  For example, a popular stereotype is that an Agile project consists of just a bunch of “cowboy software developers” who get together and start writing code without any plan and discipline about how it is done.

Is Agile and Scrum Anti-engineering?

If you have that view, it’s easy to come to the conclusion that Agile is not a very sound approach to engineering at all because it doesn’t necessarily follow a well-planned and systematic engineering design approach but it would be a mistake to draw that conclusion.  If it is well-executed, an Agile approach requires a considerable amount of discipline and skill and it’s not “anti-engineering” – it is just a different kind of engineering.

Importance of a Systematic Engineering Design Approach

Let’s step back and look at when and where a well-planned,  systematic engineering design approach really makes the most sense.  That kind of approach is most important for problems that have a high level of technical complexity and the aim is to find an optimum solution as quickly and efficiently as possible:

“A systematic engineering design process model aims at making it easier to find an optimal design for a product-to-be. To that end it is necessary to encompass the broadest range of solutions, that is, to search for solutions in a structured, systematic way. The breadth-first top-down strategy is adopted,  which means first finding the largest possible number of abstract solutions (breadth-first) and then more concrete ones (top-down)”
https://www.designsociety.org/download-publication/26782/a_review_of_the_fundamentals_of_systematic_engineering_design_process_models

A good example of that might be a very data-intensive application that might start with a high-level, conceptual design phase, proceed to a logical design phase, and then finally wind up with a detailed physical design of the solution.  To do that efficiently, you will want to stabilize the requirements as early as possible because each phase cascades into the next.  You don’t want to get all the way into the detailed physical design and discover some of the critical assumptions made in the previous phases were wrong because it could require a significant amount of rework of the whole design.

However, there are many people who believe that a well-planned and systematic approach to engineering is the only way to do engineering.  Here’s an example:

“The design of complex, complicated or a family of products is usually beyond the intuitive skills alone of a designer or design team. Gerhard Pahl and Wolfgang Beitz [1] have set out a strategy for the development of solutions which aims to increase the probability of technical and economic success of product design. This is done by creating a dependable approach which allows careful planning and systematic execution so that the whole design task reduces to a logical and comprehensible exercise and also allows recovery from inevitable errors. It also allocates a time schedule for the design stages which in turn leads to a predictable project timetable. Systematic design is general enough to be applied in any branch of engineering.”
http://theoriesaboutengineering.org/gerhard_pahl_and_wolfgang_beitz.html

When Does a Systematic Engineering Design Model Make Sense?

That well-planned, systematic approach to engineering design has been the predominant approach to engineering design for a long time. It has proven to be a reliable and efficient process for converging on a design solution where the requirements are relatively well-defined and the technology is also relatively stable as shown in the Stacey complexity model below:

The primary question that the design team must answer in this environment is:

“Is this solution the most optimum design solution to the requirements for this problem?”

It is primarily a pure engineering design decision.

Why Doesn’t That Approach Work in Many Areas Today?

The major problem with that approach is that we live in a much more complex world with much higher levels of uncertainty today.  In terms of the Stacey complexity model, both the requirements and the technology associated with the solution might be much more uncertain.  In that kind of environment,

  • It is no longer a simple question of “Is this solution the most optimum solution to the requirements for this problem?” and
  • Its no longer limited to relatively straightforward engineering design decisions because the requirements themselves might be wrong and the assumptions about the technology might also be wrong

In an uncertain environment, the approach needs to be much more adaptive and involve some amount of “discovery” to determine what the requirements for the solution should be.  The approach should not be limited to just implementation of a predefined  solution.  There is also typically a lot of tradeoffs between the requirements for the solution and the technical implementation that optimizes both.   Converging on a solution to those requirements without considering those tradeoffs might not yield an optimal solution.

When that kind of situation has arisen in the past, a typical approach has been to do some amount of upfront prototyping to try to converge on the requirements of a solution before actually starting on the full-scale design and development effort.  That approach works in some cases but it isn’t the most efficient or the most effective approach if there is a large amount of uncertainty in the requirements.  If there is a large amount of uncertainty in the requirements, it may take multiple iterations to converge on the requirements for the design; and, for larger and more complex projects, there may be a number of different areas of uncertainty that need to be resolved.

That’s why an Agile approach can make a lot of sense for projects with a high level of uncertainty.  It’s not really “anti-Engineering”:

  • It’s a different kind of engineering approach that is different from a typical, well-planned, systematic engineering design approach,
  • It is much more appropriate for areas that have high levels of uncertainty

It’s important to recognize that Agile is not “cowboy engineering” – if it is done correctly it requires a lot of discipline and skill.

What Does This Mean For Project Management?

Project Management is not just an administrative task – project management needs to be designed around the most sensible engineering design approach for a given problem. Traditionally, the project management approach has been heavily-based on well-accepted engineering design practices that emphasize a well-planned, systematic engineering approach. As we rethink the way that engineering is done, we also need to develop new project management models that are also better aligned with higher levels of uncertainty.

Summary of Key Points

Here’s a summary of some key points from this article:

  • There  is an intimate relationship between project management processes and engineering design processes.
  • Many people have forgotten about that relationship and think of  project management as primarily an administrative management function to manage the execution of what many people loosely call “Waterfall”.
  • Project management is more than just an administrative function – it should be geared to effectively manage an underlying engineering design process.  And, that underlying engineering design process should be geared to the nature of the problem.
  • The underlying engineering design approach that has been assumed to be well-established for so many years can no longer be taken for granted as the only way to do engineering design.  It does not provide a sufficient level of flexibility and adaptivity for a highly uncertain environment.
  • Project management must adapt as well – it is no longer viable to force-fit all projects to a project management that is based on an underlying engineering design approach that has serious weaknesses in an uncertain environment.

The challenge for project managers is learning how to blend an iterative and adaptive Agile approach with a more traditional plan-driven approach in the right proportions to fit the nature of the project and one of the biggest factors in choosing the right approach is the level of uncertainty in the project.

 

Are There Project Managers in Agile?

I recently responded to a question “Are there project managers in Agile?” It’s a good question and it comes up often so I thought I would share the answer here in my blog. There’s actually a lot of “project management” going on in an Agile project, but it’s a different kind of “project management” and you may not find anyone at the team level in an Agile project with the title of “Project Manager”.

Are there project managers in Agile?

What is “Project Management”?

Here’s a definition of “project management” that I copied from a Quora discussion forum I participate in:

“Project management is the discipline of planning, organizing, securing and managing resources to bring about the successful completion of specific project goals and objectives within the time, cost, scope and other relevant constraints”

That’s a fairly well-established definition of what “project management” is that hasn’t changed significantly since the 1950’s and 1960’s at least.  In fact, it is so well-established that many people see that as the only way to do project management and don’t even recognize Agile as a form of project management at all.

What’s wrong with that definition?

There have been many projects that have met their cost and schedule goals for delivering well-defined requirements yet failed to deliver a sufficient level of business value to offset the costs of the project.  That happens frequently in situations where there is a high level of uncertainty and risk associated with attempting to totally define the project requirements in detail prior to the start of the project. When you attempt to force-fit all projects to a traditional, plan-driven project management approach, you’re openly inviting failure if there is a high level of uncertainty in the project.

What Does a Broader Vision of “Project Management” Look Like?

What’s needed is to adopt a broader view of “project management” that is focused on producing value  and not simply meeting cost and schedule goals for well-defined requirements.  (Meeting cost and schedule constraints may be one component of value that the project produces but not the only component) That’s the challenge for project managers of the future. Project Managers of the future need to be able to take on a project with fairly broadly-defined objectives in a dynamic and uncertain environment and develop a solution to meet those objectives using whatever blend of traditional plan-driven project management and Agile principles and practices makes sense for that situation.

I recognize that is an ambitious vision and it will be difficult to achieve for many project managers to achieve but I think the survival of the project management profession depends on it. In the not-too-distant future, project managers who only know how to manage projects using a traditional, plan-driven approach to project management will become dinosaurs in many industry and application areas, in my opinion.

What is Needed to Get There?

PMI is moving slowly in that direction. The creation of the PMI-ACP certification at least recognizes Agile is important for project managers to understand but it doesn’t go far enough in my opinion – Agile and traditional, plan-driven project management are still treated as separate and independent domains of knowledge with little or no integration between the two and it is left completely up to the individual project manager to figure out how to put the two approaches together.

That is exactly the goal I have established for the online Agile Project Management training curriculum I’ve developed – to help project managers see these two approaches in a fresh new perspective as complementary to each other rather than competitive and to learn how to blend Agile and traditional, plan-driven project management principles and practices in the right proportions to fit any situation.

What Else is Different in an Agile Environment?

Another thing that is significantly different in an Agile environment is that the functions that might normally be performed by a single individual with the title of “Project Manager” are typically distributed among the members of the team at the team level rather than being done by one designated individual. For that reason, you typically will not find anyone with the title of “Project Manager” at the team level in an Agile environment.

Distributing the project management functions among everyone on the team has a lot of advantages in a dynamic and fast paced environment. Having a single “Project Manager” as a single point of focus for project management is appropriate in a traditional, plan-driven project where the emphasis is on control, but it is less than optimal in an Agile environment where there is less emphasis on control and more emphasis on flexibility and adaptivity and a single point of control can easily become a bottleneck.

What’s Left for a Project Manager to Do in Agile?

If there is no formal role for a “Project manager” at the team level in an Agile environment, the logical question is “what’s left for a project manager to do?”. There are a number of possibilities but you might not recognize any of them as a traditional project management role and all of them go beyond the skills of a traditional, plan-driven project manager.

  • At the team level, although you may not find anyone with the title of “Project Manager”, there is a need for “project management” and many of the team members may not be well-prepared to take on those functions.  In that environment, an experienced Agile Project Manager can help coach the other members of the team in how to integrate the necessary focus on project management with their work in an Agile environment. That can be done either by an Agile Coach who also has project management skills to coach and mentor the team members or by integrating someone who has project management skills with one of the other team roles such as the Scrum Master or Product Owner.
  • For various reasons, many companies will choose to implement a hybrid approach that blends an Agile and traditional project management approach.  An example would be Agile contracts.  There is a big opportunity for Agile Project Managers in this environment
  • Finally, at a higher level, there are a number of opportunities for project managers to take on larger and more complex projects and programs with multiple teams and to help companies develop a strategy for integrating Agile and traditional project management principles and practices in the right proportions with their business environment

For more on this, I suggest taking my free online training course called “How to Prepare for PMI-ACP Certification”. There is some material in that course on the potential roles that a project manager might play in an Agile environment.

The Evolution of Agile Project Management

There is a lot of confusion about the evolution of Agile Project Management – the Project Management profession is evolving and maturing:

  • From a role that is practiced exclusively by someone with the title of “Project Manager”
  • To a broad-based discipline that is much more fully integrated into the way companies do business

And:

  • From simply using a plan-driven project management approach for managing projects against well-defined requirements to meet cost and schedule goals
  • To a much broader focus on blending Agile and traditional plan-driven project management in whatever proportions are needed to drive business results in an uncertain environment

We’re still in the very early stages of that transformation, it will likely take a long time to fully evolve, and its causing some confusion and turmoil because its not totally clear how it will evolve.  However, I have seen a similar transformation happen in the quality management profession years ago and we can probably learn a lot from that.

At one time, “quality management” was something that was practiced exclusively by someone with the title of “Quality Manager” who owned responsibility for managing the quality of products and services in their company or their area of responsibility.  I was in such a role at one time – I was a Quality Manager at Motorola in the early 1990’s.  Motorola was a very large and successful company in those days, there were multiple layers of management, and the quality management chain-of-command was parallel to the normal business and operational management structure.

We were frequently getting directives from higher in the quality management chain-of-command to “go over and make the business and operational managers improve their quality in some way”.  That was a thankless role because the Quality Manager had to lead through influence and had no direct control over the people and processes he/she was trying to influence just as a project manager today may have to lead through influence.  That is very similar to the role of many typical project managers who are part of a PMO organization that doesn’t necessarily have direct control of the resources assigned to projects.

My manager at that time was very astute and enlightened and one thing I remember him saying was that “Our role is to teach, coach, and audit”, in that order.  What that means is that to be an effective Quality Manager, you can’t be an “enforcer” and you can’t be the only one who is responsible for “quality” in the organization.  A more effective approach is to engage others in the effort to improve the quality of the company’s products and services.  By teaching and coaching others to integrate quality management into the way they do their work, you can develop a much more broad-based level of commitment to quality management which was much more effective than a typical quality management “enforcement” approach controlled by someone called a “Quality Manager”.

A similar thing is happening in the project management profession today.  If you look at the way “project management” is implemented in an Agile project at the team level, you may not find anyone with the title of “Project Manager” but there is actually a lot of “project management” going on.  It’s a different kind of project management and the project management functions are distributed among other roles in the Agile team.  That’s probably a much more effective approach to project management – instead of only one person with the title of “Project Manager” being responsible for everything related to “project management”, there is a much more broad-based commitment to project management.

How does that impact project managers and the project management profession?  It is having a major impact and it’s causing a lot of confusion and turmoil at the moment.  There is likely to be a shift in the way “project management” is implemented just as there was a shift in the way “quality management” was implemented years ago.

  • The role of a PMO will likely change from an organization with an emphasis on control of all projects with a lot of restrictions and rules on how projects are managed to more of a consultative and supporting role to help others manage projects more effectively using a more adaptive approach to fit the nature of the project.
  • The role of a dedicated “project manager” will likely also be impacted.   Companies recognize the importance of “project management” and don’t want to give up that discipline but having a dedicated role called a “Project Manager” may not be the best way to preserve that focus.   As a result, some companies are trying to find people with project management skills who can also play other roles such as a Scrum Master or a Product Owner.

This is an evolving transformation, we are in the early stages, and I don’t pretend to have all the answers of exactly how it will evolve but there is no question that there is a transformation going on that we can’t ignore.  The curriculum that I’ve developed in the Agile Project Management Academy is designed to help project managers transform themselves into a high impact Agile Project Management role to align with this overall transformation in the project management profession.

 

What is an Agile Project Manager?

I’ve participated in some discussions recently that indicate that there is still a lot of confusion and controversy about what is an Agile Project Manager is. It’s understandable why this confusion exists:

  • There have been some very strong stereotypes built up over many years of what “project management” is and what a “Project Manager” is.  Those stereotypes are centered around the belief that “project management” is limited entirely to traditional plan-driven project management and project managers are so heavily engrained into that way of thinking that they can’t possibly adapt to an Agile environment.
  • PMI has made a step in the right direction by introducing the PMI-ACP certification.  That certification at least recognizes Agile as a legitimate form of project management but PMI has never really defined exactly what an “Agile Project Manager” is and what role he/she might play in the real world.
  • Many people think of Agile in a very narrow sense as limited to simple, single-team Scrum projects; and, because there is no “Project Manager” role defined at that level, they assume that there is no role for Agile project management at all in an Agile environment; however, there is more to Agile than simple, single-team projects.

In order to better understand what “Agile Project Management” is, we need to get past these stereotypes and develop a broader vision of what “project management” is, what “Agile” is, and what an “Agile Project Manager” is.

First, we need to recognize that the discipline of ”project management” isn’t limited to traditional, plan-driven project management with an emphasis on planning and control just because that’s the way project management has been typically practiced for many years.  There is actually a lot of “project management” going on in an Agile project although it may not look like the traditional, narrow view of what project management is at all:

  • It’s a different style of project management with an emphasis on taking an adaptive approach to maximize the value of the project in an uncertain environment rather than the traditional emphasis on planning and control; however, if you take a broader view of what “project management” is, it is still project management.
  • And, although you may not find anyone with the title of “Project Manager” at a team level in an Agile project, there’s a lot of project management going on – the project management functions that would normally be performed by an individual with the title of “Project Manager” have just been distributed among the other members of the team:
    • The Product Owner has a lot of responsibilities that might be performed by a project manager in a traditional plan-driven project.  He/she is responsible for the overall successful business outcome of the project which means delivering a valuable product in a timely and cost-effective manner and making all decisions that would normally be done by a Project Manager for risk management as well as planning and managing the overall effort.
    • The Scrum Master also has some responsibilities that might be done by a project manager including removing obstacles and facilitating the project team.  It may be a different style of leadership, but it is still leadership.
    • And, finally every member of the development team has some project management functions on a very small scale for planning, scheduling, tracking, and reporting on their own work as well as the work of the team as a whole.

A related stereotype is that many people think that there is a binary and mutually exclusive choice between “Agile” and “Waterfall” and try to force-fit their projects to one of those extremes when a better approach is to go in the other direction and fit the methodology to the project.  And, “Agile” and traditional plan-driven project management are still treated as separate and independent domains of knowledge with little or no integration between the two.  There are many projects that call for blending those two approaches in the right proportions to fit a given situation particularly as you get into larger, more complex, enterprise-level projects.

So what is an “Agile Project Manager”?

In my opinion, an Agile Project Manager is equally trained and skilled in applying both Agile and traditional plan-driven project management principles and practices and knows how to blend them together in the right proportions to fit a given situation.  That is exactly what the training I’ve developed is all about – it is designed to:

  • Help people see “Agile” and traditional plan-driven project management in a fresh new perspective as complementary rather than competitive, and
  • Help project managers better understand what “Agile Project Management” is and what they need to do to prepare for it

So What role might an “Agile Project Manager” play in a real-world project?

I think it’s sad that some project managers see there only alternative in an Agile environment is to become a Scrum Master because the role of an Agile Project Manager is so ill-defined and poorly-understood.  I hope that the Agile Project Management training curriculum I’ve developed can help project managers see this new perspective and lead the rest of the profession into demonstrating successful Agile Project Management leadership. In my training, I’ve identified several potential roles that an Agile Project Manager might play:

  1. Team-level Role – There is officially no role for an “Agile Project Manager” at the team level in an Agile project; however, a project manager who is skilled in blending Agile and traditional plan-driven project management principles and practices can play a real value-added role as either a Product Owner, a Scrum Master, or an Agile Coach
  2. Hybrid Agile Role – For lots of reasons, companies choose to implement a hybrid Agile approach and this is an ideal environment for an Agile Project Manager to work in. An example would be an Agile contracting situation.
  3. Enterprise-level Role – As projects grow in scope and complexity to an enterprise level, there is a much more significant need for a dedicated Agile Project Manager role. As an example, I did a case study in my latest book on a project at Harvard Pilgrim that involved over 100 Agile teams – you just can’t do an effort like that without some form of project/program management

My training includes much more detail on this and several real-world case studies illustrating each of these roles.