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.”
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.
Here are some fundamental things that need to be done:
- 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
- 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
- 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.