I recently saw a question on a LinkedIn discussion group asking:
What is role of a PMO in an Agile/Lean organization?
There are many people in the Agile community who might say that there is no role for a PMO in an Agile/Lean environment and that the whole concept of a PMO is inconsistent with Agile. That opinion is based on a stereotype that the role of the PMO is heavily associated with controlling and enforcing rigid waterfall-style policies for selecting and managing the execution of projects and programs. In that kind of environment, a PMO might require:
- Very thorough and detailed upfront planning to justify the ROI on projects to support rigorous project/product portfolio management decisions
- Rigid control of project execution to ensure that projects meet their cost and schedule goals and deliver the expected ROI
There is no doubt that some PMO’s have played that kind of role to some extent in the past; however, it is a stereotype to believe that is the only possible role for a PMO to play. A related stereotype is that many people also see the choice between Waterfall and Agile methodologies for projects as a binary decision – that stereotype is that an organization is either:
- Totally “Waterfall” with extensive upfront project planning as well as rigid policies and controls over how projects are executed, or
- Totally “Agile” with zero upfront planning and no policies and controls over project execution
Neither of those extremes is realistic in actual practice and you have to use good common sense to fit the right level of upfront planning and control to the project and business environment that the company operates in.
Many people make the mistake of seeing this as a binary decision and force-fit projects to one of those two extremes when the right solution is to fit the methodology (or combination of methodologies) to the project and business environment. It takes more skill to do that – it requires knowledge of a broader range of methodologies as well as a deeper understanding of the principles behind them to know how to blend traditional project management and Agile principles and practices together in the right proportions and customize them as necessary to fit a given situation.
I believe the role of any PMO is to align the selection and execution of projects and programs with the organization’s business goals which includes Project/Product Portfolio Management, providing oversight of project execution and the overall interface for management and reporting of projects and programs to senior management and the business, and finally to provide coordination, guidance, and training to project teams as needed in the organization’s methodologies and standards for project management.
Those general functions probably don’t change in an Agile/Lean project environment, but how a PMO performs those functions may change significantly depending on the organization’s overall strategy for implementing an Agile transformation.
- Some organizations may choose to implement a relatively complete top-to-bottom Agile transformation for their business – Dean Leffingwell’s Scaled Agile Framework (SAFe) is an example of such a model.
- However, that can be a very ambitious and gut-wrenching change for many organizations. It also may not be the best solution. I think it is a mistake to believe that you have to force a company to do an extensive, top-to-bottom Agile transformation in order to adopt an Agile process at the development level.
Organizations typically have different layers of management as shown in the diagram below; and, at each level, there is a choice of taking more of an Agile approach or more of a traditional, plan-driven approach:
At the business management level, the approach should be designed around what makes the most sense for the company’s business and that may or may not be exactly the same as the approach used to manage projects at the development level.
- An Agile development process is easiest to apply in companies whose primary business is developing software products (Such as Intuit QuickBooks and TurboTax) or companies where software development has a very direct and significant leverage effect on the company’s business (Such as Amazon.com). In those companies, there is a fairly direct alignment between a company’s overall business management goals and an Agile development process.
- In companies where that is not the case, the alignment may be less direct. For example, it may or may not be totally realistic for a company to adopt a complete, top-to-bottom Agile approach for their entire business and a more traditional, plan-driven approach may be appropriate at the higher levels (at least as an interim solution). However, that doesn’t preclude implementing a totally Agile or hybrid Agile development process. The Managed Agile Development process is an example of a hybrid Agile approach that can be used in that kind of environment.
The role of the PMO should be aligned with supporting whatever that overall strategy is. For example,
- The PMO may still be the focal point for Project/Product Portfolio Management, but a more agile approach might be used to perform that function. Instead of very rigorous upfront planning that might be required to analyze project ROI to support a more traditional, plan-driven project/product portfolio management approach, a more dynamic decision-making process might be used at that level with a much more limited amount of upfront planning and less detailed ROI analysis.
- In the other functions related to managing the execution of projects, the PMO probably would probably delegate more responsibility to project teams and play more of a facilitative and consultative role to support the project teams rather than playing a controlling role.
- Agile certainly forces some rethinking of the role of a PMO but it doesn’t necessarily make the whole concept of a PMO obsolete and irrelevant, and
- There are a wide range of strategies an organization can choose for implementing an Agile transformation at an enterprise level and it isn’t necessarily a binary choice between a pure “Waterfall approach from top-to-bottom or a totally “Agile” approach from top-to-bottom. You have to choose the right approach to fit the business rather than attempting to force-fit the business to some kind of “textbook” approach.
The important thing to recognize is that this is not a “one size fits all” decision. What is the right approach for one company may not be the best approach for another. It’s kind of like a chess game to choose the fit the right strategy to each level of the organization as shown in the diagram below: