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

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

Choose the Right Agile Approach for Your Business

Choose the Right Agile Approach for Your Business

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

Creativity and Innovation versus Predictability, Planning, and Control

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

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

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

Impact of the Company’s Business Model

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

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

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

Impact of Financial Planning Model

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

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

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

      What’s the Solution?

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

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

    • Related Articles

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

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

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

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

What Does 'Waterfall' Really Mean?

What Does ‘Waterfall’ Really Mean?

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

Dr. Winston Royce’s 1970 Waterfall Paper

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

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

What Was Life Like Prior to ‘Waterfall’?

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

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

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

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

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

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

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

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

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

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

How Did ‘Waterfall’ Evolve to Solve These Problems?

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

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

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

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

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

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

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

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

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

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

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

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

Overall Summary

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

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

Free Agile versus Waterfall course

Are Agile and Six Sigma Complementary to Each Other?

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

 

Are Agile and Six Sigma Really Complementary to Each Other?

The objectives behind numerous approaches such as:

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

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

The Fundamental Problem

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

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

An Example With Six Sigma

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

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

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

The Key Factor for Success

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

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

Are Agile and Six Sigma Really Complementary To Each Other?

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

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

How Can These Approaches Be Complementary Rather Than Competitive?

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

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

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

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

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

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

  •  

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

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

The importance of “Systems Thinking”

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

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

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

 

What is Systems Thinking?

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

Overall Summary

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

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

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

Is Project Management Obsolete – What Do You Think?

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

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

Is Project Management Obsolete

Examples of Companies and Professions Reinventing Themselves

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

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

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

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

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

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

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

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

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

How Does This Relate to Project Management?

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

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

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

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

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

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

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

In today’s world:

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

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

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

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

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

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

What Has Been Done to Transform the Project Management Profession?

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

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

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

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

There are at least two major problems with that definition:

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

Summary – Is Project Management Obsolete

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

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

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

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

How Do You Improve Team Performance in a Project Environment?

I recently responded to a question about “How do you improve team performance in a project?  It is very common for project managers to over-manage teams and I think that is a mistake.  A team is like a dynamic organism and rather than simply putting pressure on the team to improve performance, a better approach is to understand the dynamics of how a team performs and work on the factors that impact improving performance.  An even better approach is to help the team become self-organizing and take responsibility for improving their own performance.

What is a Self-organizing Team?

Here’s a good definition of a self-organizing team from the Scrum Alliance web site:

“A group of motivated individuals, who work together toward a goal, have the ability and authority to take decisions and readily adapt to changing demands”

The diagram below shows a comparison of a traditional project team and a self-organizing team:
What is a Self-organizing Team

Does This Mean Abdicating all Responsibilities to the Team?

The principles behind empowered teams can be used in any project. It is just different levels of empowerment.  The diagram below shows a comparison of different levels of empowerment:

How Do You Improve Team Performance

http://www.stevedenning.com/Radical-Management/most-high-performance-teams-are-self-organizing.aspx

Here’s a description of each of these levels:

  •  The lowest level of empowerment is a “manager-led team”.  In that environment, the only responsibility delegated to the team is for managing the execution of tasks that they are responsible for.
  • At the other extreme is a “self-governing team” where the team takes complete responsibility for their operations including setting their own direction.  It would be unlikely to find that level in a project team but you might find a senior management leadership team that operated that way.
  • The two levels in the center would be more commonly found in a project environment.  A “self-managing team” takes responsibility for monitoring and managing work process and progress.
  • A “self-organizing team” goes beyond that and takes responsibility for designing the team including defining roles within the team and defining the organizational context of how the team operates.

An important point is that “self-organizing” does not mean that a team does not need any direction at all. Self-organizing teams should not be used as an excuse for anarchy.

What Are the Advantages of Empowered Teams?

There are a number of advantages of empowered teams:

  • It more fully utilizes the capabilities of the people on the team
  • It reduces the need for someone to directly manage all aspects of how the team operates
  • It improves team performance because the team takes more responsibility for managing its own performance
  • Team performance is more sustainable because the performance of the team is more self-correcting
  • It encourages creativity and innovation and enables the team to quickly adapt to new problems and challenges

How Do You Improve Team Performance?

Project Managers have a tendency to over-manage the performance of teams because the perception is that is what a Project Manager or Team Leader is supposed to do; however, in many cases, simply putting pressure on the team to improve performance may not be the best thing to do. A more proactive and more sustainable approach is to better understand how the team functions as a dynamic organism and work on the factors that drive performance.

In an Agile environment, if there is a project manager involved at all at the team level, that project manager needs to be more of a coach to help the team improve its own performance. However, there is no reason why the idea of empowered teams is limited to an Agile environment.  The same ideas can be applied in a traditional plan-driven environment; however, it may involve somewhat less empowerment.

  • In a traditional project team, a Project Manager or Team Leader typically provides direction to the team and he/she is the one who is held responsible for the performance of the team and the results that they produce.    In a traditional plan-driven project, some level of control may be needed to manage conformance to the project plan; however, even in that kind of environment, it is essential to delegate some level of responsibility to the members of the team.
  • In an Agile project, there is a much higher level of emphasis on creativity and innovation rather than conformance to a plan.  In that kind of environment, it is very important to fully empower all the members of the team to actively contribute to the solution as much as possible.

This obviously takes some skill to do effectively but it definitely can be done.  I think this is an extremely important area for Agile Project Managers and I have been adding a lot more focus in my Advanced Agile Project Management curriculum to help project managers learn how to deal with these challenges.  Udemy students can find the equivalent information on my Udemy courses here.

What Is Servant Leadership and How Does It Relate to Agile?

“Servant Leadership” is a commonly-used term in an Agile environment but if you asked people what it means, I’m sure you would get a number of different responses. For that reason, I think it is worthwhile to discuss “What Is Servant Leadership and How Does It Work in Agile?”

What Is Servant Leadership?

“Servant leadership” sounds like a manager who does nothing but get coffee, donuts, and pizza for the Agile team. Is that what it really is? (I don’t think so)

The phrase “servant leadership” was coined by Robert K. Greenleaf in “The Servant as Leader”, an essay that he first published in 1970 long before Agile came into being.   Here’s a definition of “servant leadership”:

“Servant leadership is characterized by leaders who put the needs of a group over their own. These leaders foster trust among employees by holding themselves accountable, helping others develop, showing appreciation, sharing power and listening without judging. While serving and leading seem like conflicting activities, these leaders are effective initiators of action.”

http://www.ehow.com/list_6753156_servant-leadership-games.html?ref=Track2&utm_source=IACB2B

A “servant leader” doesn’t necessarily completely abdicate the leadership role and do nothing but get coffee, donuts, and pizza for the team.  He/she recognizes the importance of working through others and engaging and empowering others to use as much of their own capabilities as possible.  Here’s an excellent quote on that:

“The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first.

The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons?

A servant-leader focuses primarily on the growth and well-being of people and the communities to which they belong”

https://www.greenleaf.org/what-is-servant-leadership/

What is Servant Leadership?

What Does it Really Mean to be a Servant Leader?

A major leadership principle that is applicable to any leadership role is that there is no single leadership style that works in all situations. A good leader should be capable of taking an adaptive and situational leadership approach that is appropriate to the people and the environment he/she is trying to lead.

With regard to servant leadership, the way the servant leader role is implemented will be very dependent on the capabilities of the Agile team you are leading and the environment you are part of. The goal should be to maximize the utilization of the capabilities of the entire team but that doesn’t mean a servant leader completely abdicates a leadership role and turns over all responsibility to the team. Determining the most effective servant leadership role requires some judgement:

  • If the team is very strong and very capable, the role of the servant leader may be limited to a facilitation role
  • If that is not the case, a more active leadership role may be needed by the servant leader

Basically, the servant leader needs to “fill the cracks” as much as possible to help the team become fully effective on their own.

Why Is This Important in Agile?

The idea of “servant leadership” is particularly important in an Agile environment because an Agile approach is best suited for projects with a high level of uncertainty.  In that kind of environment, a lot of individual creativity may be needed to find an optimum solution and maximizing the creativity of the team requires that the team be empowered as much as possible.

It is basically a softer leadership style that puts an emphasis on empowering others over a more controlled approach.  It is ideal for a highly uncertain environment that requires an adaptive Agile approach.  Naturally, it probably would not be so ideal for a more plan-driven environment where conformance to a plan is important.

To learn more about “Servant Leadership” and “Agile Leadership” in general, check out my Advanced Agile Project Management course. I’ve just added twelve new lessons on Agile Leadership to the course.

What is Emotional Intelligence and Why Is It Important?

I just finished creating a significant training module on Agile Leadership and one of the key topics in that module is “Emotional Intelligence”.  I’m sure some people are wondering “What is emotional intelligence and why is it important?”  I’d like to summarize some of that here.

What Is Emotional Intelligence?

First, here’s a definition of “emotional intelligence”:

“Emotional intelligence is the ability to identify and manage your own emotions and the emotions of others. It is generally said to include three skills:

  • Emotional awareness;
  • The ability to harness emotions and apply them to tasks like thinking and problem solving; and
  • The ability to manage emotions, which includes regulating your own emotions and cheering up or calming down other people.”

https://www.psychologytoday.com/basics/emotional-intelligence

What Is Emotional Intelligence and Why Is It Important?

Why Is It Important?

Emotional intelligence is one of the most important skills of an effective leader. The reason that emotional intelligence is so important to leadership is that if you can’t control your own emotions; it will be difficult, if not impossible to be an effective leader.

Here’s a quote that sums up the value of emotional intelligence very well:

“We probably also know people who are masters at managing their emotions. They don’t get angry in stressful situations. Instead, they have the ability to look at a problem and calmly find a solution. They’re excellent decision makers, and they know when to trust their intuition.”

 

“Regardless of their strengths, however, they’re usually willing to look at themselves honestly. They take criticism well, and they know when to use it to improve their performance.”

https://www.mindtools.com/pages/article/newCDV_59.htm

What Are the Benefits of Emotional Intelligence?

Here are some of the key benefits of developing emotional intelligence:

  • Increased leadership ability because your leadership approach will be based on sound, rational principles rather than being dominated by emotional responses
  • Increased team performance because team members will feel much more comfortable and secure in a non-threatening team environment with no hidden agendas
  • Improved decision-making because decisions are made more objectively and rationally
  • Decreased occupational stress because there will be less emotional tension involved in the work environment
  • Reduced staff turnover because there will be fewer emotional flare-ups
  • Increased personal well-being because learning to accept yourself and gain control of your emotions can lead to a much happier life

How Do You Improve Emotional Intelligence?

The following tips have been reproduced from the Mind Tools web site (https://www.mindtools.com/pages/article/newCDV_59.htm):

  • Observe how you react to people – “do you rush to judgement before you know all the facts? Do you stereotype? Look honestly at how you think and interact with other people. Try to put yourself in their place, and be more open and accepting of their perspectives and needs.”
  • Look at your work environment – “Do you seek attention for your accomplishments? Humility can be a wonderful quality, and it doesn’t mean that you’re shy or lack self-confidence. When you practice humility, you say that you know what you did, and you can be quietly confident about it. Give others a chance to shine – put the focus on them, and don’t worry too much about getting praise for yourself.”
  • Do a self-evaluation – “What are your weaknesses? Are you willing to accept that you’re not perfect and that you could work on some areas to make yourself a better person? Have the courage to look at yourself honestly – it can change your life.”
  • Examine how you react to stressful situations – “Do you become upset every time there’s a delay or something doesn’t happen the way you want? Do you blame others or become angry at them, even when it’s not their fault? The ability to stay calm and in control in difficult situations is highly valued – in the business world and outside it. Keep your emotions under control when things go wrong.”
  • Take responsibility for your actions – “If you hurt someone’s feelings, apologize directly – don’t ignore what you did or avoid the person. People are usually more willing to forgive and forget if you make an honest attempt to make things right.”
  • Examine how your actions will affect others – “before you take those actions. If your decision will impact others, put yourself in their place. How will they feel if you do this? Would you want that experience? If you must take the action, how can you help others deal with the effects?”

Why Is This Particularly Important to Agile Project Management?

Check out my previous article on Agile Leadership and I think you will understand why effective leadership is extremely difficult and so important in an Agile environment with high performance teams.  Agile is based heavily on transparency and openness and if you can’t be open and transparent about who you are as a person, you will have a difficult time being effective in an Agile environment.

How Can I Learn More to Improve My Skills?

Self-awareness is one of the biggest components of emotional intelligence.  Many people aren’t even aware of who they are as a person and don’t reveal that to others.  They live their lives behind a facade that is based on projecting an image of who they are to others that may not be very genuine and others can employees can see through that easily.

When I was a young manager many years ago, self-awareness training was a standard part of many company’s management training curriculum.  The idea was that, to be an effective leader, its important to be genuine and open with others and you can’t do that without self-awareness.  Unfortunately, over the years, companies have cut back on that kind of training.  It was seen as frivolous and not essential and as pressure has mounted to reduce cost of operations, a lot of that kind of training has been cut.

I can’t really directly help you develop emotional awareness in my online training; however, I’ve added two new sections and twelve additional lessons on Agile Leadership and Emotional Intelligence in my online training that I think will be helpful to you to better understand how to develop an effective leadership strategy.  Check out the enhancements I’ve just completed in my Advanced Agile Project Management course.

What’s Really Different About Agile Leadership?

I just finished developing some online training on Agile Leadership and What’s Really Different About Agile Leadership? This article is a brief excerpt of that training.

What’s Really Different About Agile Leadership?

They’re are lots of stereotypes and myths in this area – here are a few of them:

  • Project Managers only know how to do a “command-and-control” style of management
  • Agile requires a “servant leadership” approach which means that you completely abdicate the leadership role

Those stereotypes generally follow many of the stereotypes that people have about seeing “Agile” and “Waterfall” as binary and mutually-exclusive choices with nothing in the middle of those extremes.  Instead of force-fitting a project to one of those extremes, the right approach is to go in the other direction and fit the methodology to the nature of the problem and sometimes that requires a blend of the two approaches.

Fitting the Leadership Style to the Nature of the Problem

You can make some similar observations about leadership style:

  • A good leader doesn’t have one well-defined style of leadership that he/she force-fits all situations to.
  • A good leader recognizes that different styles of leadership are needed in different situations – that’s what “situational leadership” is all about

Another important observation is that the leadership style that is most appropriate in a given situation is directly related to the nature of the project and the problem solving approach.  Here’s how I see the relationship:

What's Really Different About Agile Leadership?The nature of the problem shapes the management objective and

  • The management objective shapes the problem solving approach
  • The problem-solving approach  determines the leadership style that may be most appropriate

Real-world Examples

Here’s how that might work out in different environments:

  1. Traditional Plan-driven Project Environment – Projects that have a relatively low level of uncertainty and require some level of predictability might lend themselves to more of a plan-driven approach to project management.  An important characteristic that differentiates this kind of project is that it is assumed to be possible to define the general solution to the problem with some level of certainty prior to the start of the project.
    • Problem-solving Approach – In that approach, a defined problem-solving approach is what is typically used.  The solution to the problem is generally well-defined in advance and the general approach for implementing the solution is also fairly well-defined.
    • Management Objective – If predictability is important, having a well-defined plan and conformance to that plan are also important.  Naturally, that requires some level of emphasis on control.
    • Leadership Approach – That calls for a style of leadership that naturally might be a bit more directive in order to remain on track with the project plan.  You certainly don’t want members of the project team running loose in all different directions without some kind of plan that integrates all of their efforts together that is consistent with the overall plan.
  2. Agile Project Environment – Projects that have a high level of uncertainty generally lend themselves to a more Agile project management approach where the final definition of the solution is expected to evolve as the project is in progress rather than being well-defined upfront prior to the start of the project.
    • Problem-Solving Approach – This type of project uses a empirical process control approach.  The word “empirical” means “based on observation” which means that both the definition of the solution as well as the process to discover the solution will evolve based on observation throughout the project.
    • Management Objective – Arriving at an effective solution is far more important in this kind of project than predictability.  Therefore, innovation and creativity would generally be emphasized more than control.
    • Leadership Style – This type of project obviously calls for a different leadership style.  If you want to encourage creativity and innovation, you don’t want to emphasize control, you want to empower people and give them some flexibility to use their own intelligence and judgement to explore alternatives as necessary to find the best solution.

Overall Summary

There are a lot of very polarized viewpoints in this area that go something like this:

  • Agile is good and
  • Waterfall is bad

Or alternatively:

  • Command-and-control management is bad and
  • Agile Servant Leadership is good

Those polarized points of view tend to over-simplify what is not quite so simple as drawing a black-and-white comparison between two extremes.  There are lots of “shades of gray” in both the problem-solving approach and the leadership style that is most appropriate for a particular situation.  An effective leader should be able to adjust his/her leadership style and problem-solving approach as necessary to fit any given situation.

  • There is not just one leadership style that fits all situations
  • Leadership styles are not necessarily good or bad – saying a particular leadership style is good or bad is like saying “a car is better than a boat”.  Each has advantages and disadvantages depending on the environment you’re in.
  • Agile leadership is not really a radically different style of leadership that is totally separate and mutually-exclusive with other leadership styles; however, it significantly expands our definition of what “leadership” is.

I’ve developed a significant amount of new content for my Advanced Agile Project Management online training course that goes into this in a lot more depth.

Free Agile Project Management Webinar

Free Agile Project Management Webinar – Traditional, plan-driven project management has not changed significantly since the 1950’s and 1960’s; however, the rapid proliferation of Agile Project Management practices will bring about a transformation that will cause us to re-think what “project management” is in much broader terms.  There are many difficult challenges that must be overcome to make that transformation:

  • Agile and traditional plan-driven project management (what many people loosely call “Waterfall”) are seen as binary and mutually-exclusive choices; and, as a result, many people tend to think they need to force-fit a project to one of those extremes when the right solution is to go in the other direction and fit the methodology to the nature of the project. It can require a lot more skill to do that but it definitely can be done.
  • In the world we live in today, technologies tend to be much more dynamic and rapidly-changing and projects may have very high levels of uncertainty that make it very difficult, if not impossible, to successfully apply a traditional, plan-driven project management approach in many situations that call for a much more adaptive approach.
  • The convergence of these approaches raises the bar for the project management profession and will likely have a significant impact on the careers of many project managers.
  • PMI® has recognized the importance of Agile and has created the PMI-ACP® certification which is a step in the right direction; however, it doesn’t go far enough to address this challenge – it is only a general test of Agile and Lean knowledge; 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 up to the individual project manager to figure out how to blend those two approaches in the right proportions to fit a given situation

This presentation will help you better understand these challenges, the impact it may have on your career as a project manager, and help to begin to develop a broader, high-impact view of what “project management” is that is focused on maximizing business value using whatever blend of methodologies is most appropriate for a given situation.


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.

Blending Agile and Traditional Project Management

Protected with SiteGuarding.com Antivirus