The topic of an “Agile PMO” seems to be getting a lot of attention and there are lots of organizations that have existing PMO organizations that may be wondering what they need to do to move to a more Agile approach so I thought I would share my thoughts on this subject. It’s a controversial topic and some people might even say that the whole idea of a “PMO” is inconsistent with Agile. I don’t believe that is necessarily the case.
The key to understanding this issue is to first understand that there isn’t a binary and mutually exclusive choice between an “Agile approach and what people sometimes refer to as “Waterfall”. For more on that, check out my recent post on “Learning the Truth About Agile versus Waterfall”. It is better to think of this as a range of alternatives between heavily plan-driven at one extreme and heavily adaptive at the other extreme that looks something like this:
And, the right approach is to fit the methodology to your projects and business environment rather than going in the other direction and attempting to force-fit your projects and business to some kind of canned approach whatever it might be (Agile or not). For more on that, check out my online training course on “Making Agile Work for Your Business”.
If you accept the notion that you need to tailor the approach to fit your business, it should be evident that the design of a PMO should be consistent with that approach and there isn’t a single “canned” solution for what an “Agile PMO” is. However, I think that there are some general guidelines that should be useful. A traditional PMO organization that is oriented around a heavily plan-driven approach might look something like this:
The emphasis in this kind of organization is typically on planning and control of projects and this kind of organization would be consistent with a heavily plan-driven approach. But how does that role change as an organization moves towards more of an adaptive approach? I think a more adaptive version of a PMO organization might look something like this:
The source of the above material is from my book “Making Sense of Agile Project Management” published in 2011 by Wiley.
Here’s what I think some of the key differences are as an organization moves towards more of an adaptive approach:
- The role of the PMO becomes more of an advisory role and a consultative role rather than a controlling role. The function of the PMO should be to put in place well-trained people coupled with the right process and tools to make the process most effective and efficient and to keep it well-aligned with the company’s business
- The primary responsibility for providing direction to projects shifts more to the business side represented by the Product Owner in the projects and there is a much more of a closer coupling with the business side to put more emphasis on providing business value rather than simply managing project costs and schedules
- The role of the functional organizations also changes to providing more of an advisory function as the resources are more committed to project teams and the project teams become more self-organizing
This model can be a very big change for many businesses because it puts a lot more responsibility on the business side of the organization to provide direction to projects and the business organization may not be well-prepared to take on that responsibility. It also relies much more heavily on self-organizing teams. For those reasons and others, a totally adaptive approach may not be the right approach for all businesses and even if it is, it may take time to migrate an existing organization to that kind of approach. Fortunately, there are many ways to develop a hybrid approach to blend a traditional plan-driven approach with a more adaptive approach to fit a given business and project environment. See my “Agile Project Management Workshop for Project Managers” for more on that.
I participated in a discussion on LinkedIn this morning that stimulated my thinking. The individual who started the discussion asked the question, “If a pilot project is discontinued because it didn’t achieve results it had hoped for, would that be considered project failure?” The answer seemed obvious to me but it really stimulated my thinking – one of the key things that differentiates an Agile approach from a traditional plan-driven approach is the attitude towards failure:
- In an Agile environment, a “failure” is regarded in a positive sense as an opportunity for learning and there’s a very popular mantra of “fail early, fail often”. In other words, sometimes you just have to try something and see what works and take a risk rather than being totally risk-averse and attempting to analyze and anticipate every possible risk and contingency before you even get started.
- In a traditional, plan-driven environment, the attitude towards failure is many times very different. Any significant unexpected event might be regarded as a failure and many times is regarded negatively. There is an inference that it’s a failure in planning that you didn’t do enough upfront planning to anticipate the problem and avoid it.
I don’t think either of these two approaches is necessarily right or wrong. Like many things, it depends on the situation. There are some situations that call for a more risk-averse approach and some that don’t:
- Some businesses have to operate on the “edge of chaos” because of a highly competitive business environment. If they were overly risk-averse and had excessive fear of failure, they would not be successful in their business and that would be a failure in itself to not do anything to “push the envelope”.
Another saying I like is “If you’ve never failed, you’re not trying hard enough”. Amazon.com is probably a good example of a company that has a lot of failures like their smartphone, yet they continue to push the envelope to explore very risky new technology such as package delivery with drones because I’m sure that they feel that they need to continue to “push the envelope” to maintain their competitive position
- In other environments, the consequences of problems may be much more significant and need to be more thoroughly anticipated and mitigated. Sending an astronaut to the moon might be an example. Check out the book, “Failure Is Not an Option: Mission Control From Mercury to Apollo 13 and Beyond” for more on that
- There’s also a lot of gray area between those extremes where it may require considerable judgment to figure out what the right approach should be. Any project that involves a large amount of uncertainty might be an example. You need to figure out how much of that uncertainty you can tolerate and let it be resolved as the project progresses and how much of it you can’t tolerate and need to resolve upfront before the project starts.
It would probably be very irresponsible to take a cavalier approach and ignore the potential impact of risks; but, on the other hand, it could be equally problematic to get bogged down in “analysis paralysis” and never get started trying to anticipate and mitigate every possible risk that could possibly happen.
The most important thing is to have a clear mutual understanding and a sense of partnership between the project team and the project sponsor about what the goals of the project are, what level of risk is acceptable in the project, and how those risks will be managed.
- In an Agile project, that’s typically easier to do because the relationship with the business sponsor is based on a spirit of trust and partnership as well as openness and transparency and the Business Sponsor (represented by the Product Owner) is expected to have a sufficient level of judgment and maturity to make good, sound decisions on the project. Because there is an understanding that some of the risks and uncertainties will be resolved while the project progresses, the Business Sponsor (represented by the Product Owner) is also intimately involved as the project progresses to provide ongoing direction
- In many traditional, plan-driven environments, the business sponsors may not have that level of maturity and there may be less of a spirit of partnership with the project team. The Business Sponsors frequently put that responsibility totally on the project team to “just get it done” and don’t necessarily want to know about any risks at all. That can lead to a fear of failure and a “CYA” approach by the project team to over-analyze the project to avoid any possible problems and it can also lead to less-than-open sharing of project information to avoid airing any “dirty laundry” with the project sponsors.
It seems to me that the partnership approach where the business and the project team mutually agree on the project risks and how they will be managed is a lot more sensible and has numerous advantages.