Agile has cemented its place as a compelling tool for managing software development and Agile approaches are gaining traction in other domains as well. Despite the demonstrated value of Agile techniques, there can still be resistance to Agile methodologies from one of the biggest defenders of legacy Waterfall processes, the Project Management Office (PMO). This resistance can be due to uncertainty about the role of the PMO in an Agile world, perceived flaws in Agile approaches, or concerns about the suitability of Agile to the organization’s unique circumstances. Meanwhile, Agile best practices have little to say about the role of the PMO and to some Agile practitioners “the PMO is a despotic and despicable ‘process police’”
This conflict is damaging to an organization’s morale, culture, and ability to successfully leverage Agile. It’s also rooted in a narrow interpretation of the role of the PMO on the part of Agile practitioners and inflexibility on the part of PMOs. Organizations will be much better served by a broader understanding of the role the PMO plays and an acknowledgement of the value it can provide in helping Agile to fit smoothly in to existing processes and structures.
What’s a PMO anyway?
Part of the confusion over the role of the PMO is that there’s no one definition of “PMO” – they come in a wide range of sizes, have varying degrees of influence, and perform functions from delivery to strategic planning, depending on the needs of the organization.
PMOs with the smallest scope are responsible for delivering a single particularly large project or program, coordinating the efforts of multiple project managers working on various aspects of the initiative. The largest PMOs, sometimes called “Enterprise PMOs,” provide portfolio management (overseeing strategic investments and operational improvement budgets, balancing risk profiles, and tracking ROI), a suite of related services like business analysis and change management and have strong, established relationships with stakeholders throughout the business.
In between, PMOs govern the projects of departments of all sizes and serve as “centers of excellence”: defining best practices, establishing a standard project management methodology and templates for a given department or the entire organization, and monitoring compliance to ensure consistency and quality. They may also do the hiring and managing of project and program managers, maintaining a bench of internal staff or contracting outside resources as needed.
The Role of the PMO in Agile
Other than project management, most Agile methodologies have little to say about how the above functions are to be performed. Scrum, for example, hides much of the value stream behind a single role: the Product Owner. However, the bulk of what most organizations do is outside the world of the Agile software development team and there are opportunities for the PMO, whatever its form, to contribute to aligning that broader context and Agile initiatives. As an organization adds Agile methods to its toolkit, the PMOs role, with some adaptation, remains critical to success.
In an Agile world, PMOs can work with Agile practitioners to:
- Establish guidelines to determine what method, Agile, Waterfall or some mix of the two, is best suited to the opportunity at hand
- Staff projects with personnel that are experienced in Agile or Waterfall, depending on the project
- Provide large Agile initiatives with a centralized office to coordinate the efforts of the various work streams (though this office may take the form of a “Scrum of Scrums” or other similar structure)
- Provide other services, like business analysis and change management, that are no less relevant to Agile contexts
- Vet projects for their alignment with strategic objectives, expected ROI, and risk profile
PMOs will also need to adapt to Agile principles, working to:
- Give teams much more leeway to structure their work in the way that works best for them
- Focus governance on the value produced over performance-to-plan
- Accept documentation-light management as healthy in Agile projects - Agile initiatives may not build and maintain a detailed project plan (though they should have a dynamic roadmap and backlog)
- Treat future scope in Agile initiatives as comparatively flexible, even unspecified
- Address pressure on budgeting processes which have historically been based on devising an estimate for a given scope of work – Agile initiatives flip this around and seek a stable team and a set amount of time (i.e. budget), working out what they need to do (i.e. scope) to maximize value as they go
- Evolve portfolio management to corral initiatives pursued with different methodologies
For their part, Agile practitioners and teams must accept some constraints, embrace their role as only a part of a broader organization, and collaborate on optimizing the end-to-end value stream, not just the Agile team. They can do this by working with the PMO to:
- Meet minimum quality standards and comply with regulations
- Establish methodology and tool set guardrails - stakeholders will reasonably expect some process uniformity from team to team, it will be otherwise impossible to have a clear sense of the performance and status of the organization’s portfolio, and new Agile teams will benefit from a “menu” of light frameworks used throughout the organization so they don’t need to reinvent the wheel
- Define performance metrics appropriate to the model in use, but also that work for all initiatives, like estimates of business value delivered – a known challenge for Agile initiatives according to a recent Forrester report.
Finally, organizations will need visionary project and change management support for the deployment of Agile in the organization. Stakeholders throughout the business must be engaged, starting with senior leadership, and resistance to adoption managed appropriately. Outside talent with deep experience in Agile methodologies will be required to coach the project teams or departments that are adopting the new frameworks, while internal expertise in the organizational culture and history will be needed to develop a thoughtful implementation plan. Finding the balance between optimizing work for individual Agile teams and the organization as a whole should be approached carefully in a spirit of open-minded exploration. What works for one organization may not work for another, so each organization should consider a variety of methods to find the best combination for its unique needs.
With the competitive pressures organizations face in today’s markets, companies need to have a range of tools at their disposal and leverage those tools intelligently. PMOs should embrace Agile, become experts in it and help their organizations figure out how to successfully integrate the new practices into their business. Meanwhile, Agile practitioners need to understand and recognize the critical value that PMOs have provided historically and the opportunity for them to continue to play a key role in an Agile world. Rather than viewing one another with suspicion, PMOs and the world of Agile should engage in a mutually beneficial collaboration — they’ll both be stronger for it.