What is the PMO?
Wikipedia says that the PMO is the Project Management Office and is defined as “in a business or professional enterprise is the department or group that defines and maintains the standards of process, generally related to project management, within the organization.” It goes on to reference traditional project management methodologies like the PMBOK and newer standards like ISO9000.
There are other references to PMO being the Program Management Office. However most of these references still discuss program management in the context of project management.
I would like to take a deeper look into what the PMO should be to the enterprise and how the traditional focus of project management may fall short of what the enterprise really needs.
What does the enterprise ask of the PMO?
All large organizations have projects that need to be managed. This is the traditional primary focus of the PMO. How do we know that at project is being well managed? To understand what it means to have a well-managed project, we need to examine the goals of project management.
The common response when you ask a project manager what their goals are, their response is about the on-time and on-budget completion or the project. That sounds like a good idea, but what does it really mean?
Obviously this indicates that there are goals for the completion date and the cost of the project. That has an enormous hidden meaning. The assumption is that project management knows what the project really is, what it will take to “complete” the project and the effort and skills that it will take to “complete” the project.
Second, there is an implied understanding of the risks involved in the project. These would include platform and technical risks, business risks, competitive risks and probably domain specific risks. Probably the most overlooked risk is the absolute risk of the organization’s ability to actually “complete” the project.
The last major responsibility that I have seen in large enterprises is that the PMO is responsible for the “efficient use of resources”. Translation – keep everyone busy! (We are not paying them to do nothing!)
There are also several ancillary responsibilities that the PMO must often attend to for the enterprise and senior management. The first of these is the reporting of project status, especially the roll-up reporting aligned to enterprise budgets and goals. This is harder than it appears on the surface. Projects are often and traditionally tracked by effort measured in some time scale like hours or by expenditures against a budget.
The PMO is also often charged with the responsibility of increasing project success over time through the development, implementation and enforcement of appropriate project templates, policies, tools and standards.
In addition to all of these, there is often a requirement to plan, coordinate and prioritize the various programs and goals of the enterprise. This is often referred to as portfolio management. Portfolio management often requires another roll-up of reporting across projects to an enterprise view. Portfolio management is often a strategic coordination to meet enterprise goals. This also means that the PMO is often responsible for the efficient allocation of scarce “resources”, skills and equipment.
At the lowest level the PMO is also expected to be self-sustaining through the training and mentoring of junior project managers.
Inherent to all these responsibilities are the expectations that the PMO will recognize and effectively deal with delays, unforeseen cost increases, changing priorities and projects that fail.
The Traditional PMO and Agile Project Mismatch
There is increasing adoption of agile approaches and methods in enterprise software product development. The growing awareness of Scrum especially is creating an increasing pressure on organizations to attempt to compete better by implementing Scrum or at least being more “agile” in software product development. This pressure is coming from a number of sources. There is literature and case study evidence that enterprises can deliver business value faster, produce higher quality software, retain and attract technical talent and better understand the state of project development through the implementation of agile practices and methods.
The pressure created by the desire to be more agile creates a number of mismatches for the traditional PMO. The traditional goals and approaches used by the PMO often create obstacles[1] to project success and the consistent and sustainable delivery of business value. These obstacles require a reassessment of the traditional PMO goals and the approaches used to fulfill PMO responsibilities. Alistair Cockburn says “Software is a cooperative game”. In other words the, PMO should look at the process of software development as a goal-oriented, collaborative, group activity with a specific end. When we look at each of the traditional responsibilities of the PMO, we can identify strategies and activities that are more effective and remain consistent with the enterprise goals.
Monitor and Manage Projects
Traditionally the PMO is expected to monitor and manage projects. The concept of control is commonly used in this context. The idea of control often includes steps, gates and sign-offs. One example of this is to track the progress against measures like fully completed and signed off documentation. This documentation provides a plan or roadmap to the completion of the project’s features and deliverables. This roadmap facilitates the creation of a timeline and budget for the project.
The PMO of the future should track the software game. Are we going to win? What is the score? Where are we in the game? How are the players doing? Is the team healthy? Consider the manager or coach or a sports team. Does the field manager or coach “control” the game or the team? Consider the length of a game. Does a team in baseball win by playing 9 innings? Consider the reality of the score of the game. Does the strategy of a football game change when the score is lopsided?
The PMO needs to understand the score. Are the features being developed at a pace that will result in a release that will deliver appropriate business value? Will the expectations of stakeholders and management be upheld at the pace the team is on? How can the PMO monitor the project to provide the enterprise the ability to select the best course to deliver the most business value as early as possible? To answer these questions, the PMO of the future should be able to measure business value and the pace at which it is being developed and delivered. The PMO of the future should be able to report on this progress in the terms of the system capabilities being delivered and the business capabilities they will enable and support.
Develop and Implement Standards
The traditional approach here is to develop and enforce a methodology to achieve a consistent ability to measure and monitor the projects. The result is the institutional adoption of a process aimed at measuring “performance” against the plan developed to fund and authorize the project. That performance is often stated as a rate of expenditure compared to a budget and timeline.
To track the game and the score, the PMO needs to develop measures that support the goals of the project. To win the game iterative and incremental planning and development are combined with the close business involvement and frequent retrospectives of Scrum. This means the “score” needs to be known in terms of business value or actual business capabilities delivered rather than dollars, bugs or stage gates. Most successful Agile teams use a story based approach to work breakdown and properly defined stories can be sized in such a way as to increase predictability and measure business value delivery.
Managing Multiple Projects
The approach for managing multiple projects is often to flow job specialties over multiple projects in a sequential process. In other words architects and business analysts should finish their work on a project early so that the coding, testing, documentation, integration and release can be done on schedule as the people with those specialties become available. Often this results in individuals working on 4 or more projects simultaneously because of the need to revisit areas of the project where previously “completed” phases need to change to meet new requirements, new learning or technology changes. This increases the contention for scarce skills and equipment further delaying the delivery of business value.
The use of a business value, story driven approach where all aspects of a story are developed collaboratively in the context of the current state of the product architecture and release goals, can deliver more business value faster and result in less rework later. This allows entire deliverable increments of business value to be developed and delivered more quickly than the traditional multiple project phased approach. While the prioritization of all projects against each other is required, normally the most important projects are delivered earlier.
Strategic Planning and Road Mapping
Most organizations believe that they do strategic planning for software development. However the approach is commonly one of loading as much as will possibly fit in a milestone or release in an effort to maximize efficiency and throughput. This impacts the project planning process and obscures the internal complexity of the solution as well as the real relative priority between various business capabilities. This approach also makes it difficult or impossible for the enterprise to quickly change priorities due to the very heavy investment in partially done work.
The breakdown of work at the portfolio level for enterprise agility involves the identification of business capabilities and the required system capabilities to deliver them. This is often a matrix of business and system components that can and should be prioritized to deliver business value early and often. It is not uncommon for such an analysis and road map to deliver some features with significant time and cost savings due to the leveraged priorities of the components. From a code quality point of view, this also can deliver components that are truly reusable with higher maintainability which can result in an increasing pace of business value delivery. The strategic adoption of the goal to deliver smaller components more often rather than the full feature bus approach is the key to igniting this engine of performance.
Facilitating Enterprise Learning
The auditing of projects against up-front plans and schedules seldom has a positive impact on the teams and the organization. Attempting to hold matrixed individuals accountable to aggregate project goals is almost nonsensical. The desired outcome of project auditing should be a better chance that the next project will deliver more business value faster. However measuring against a traditional up-front project plan has very little chance of improving the next project or providing an accurate view of the current project.
Yet there are lessons to be learned. The audit report indicating that a particular feature was late by 50% of the original estimate should trigger the question of why that happened and more important, how can the organization be more predictable and/or deliver business value sooner in the future? There is an aspect of this problem that does relate to the skills required to provide workable estimates. Agile teams do learn to have better estimates over time. However the learning to improve predictability often has little to do with hours, days and weeks. Teams need to understand the nature of the work and have the authority to do the best work in a given time frame. I’m not going to delve deeply into the use of non-time based sizing, but what is important in this context is to understand that the PMO should treat the work to get the funding as a discrete project,separate and with different goals from the project of delivering the best business value as soon as possible. The culture of constant prioritization of user focused business capabilities, right sizing stories and allowing the team to do the best quality work possible can lead to more predictable and faster delivery of business value if the process includes the effective use of automated acceptance and unit tests, checkpoints and retrospectives to identify errors and correct them as early as possible.
Conclusion
The enterprise expects the PMO to provide value through the management of programs and projects. Managing projects is the primary responsibility of the PMO. When the organization or the development teams decided to change their process to adopt Scrum, things will change for the PMO. The focus of Scrum and the foundational principles is the delivery of business value faster. The PMO of the future will need to monitor and manage the various projects in relation to the delivery of business value.
To be able to provide this business value relevant progress reporting and help the organization understand the status of the projects, the PMO will probably be involved in the creation of sizing, planning and tracking systems that use the relative ROI sizing concepts used by Agile teams.
Most enterprises have more than one software product under development. This almost always means that there are some cross-project priorities that need to be managed. Many times there is a significant opportunity for a PMO to actually accelerate the pace of real business value delivery by taking a portfolio, business capability and system capability approach and delivering smaller packages of business value more often.
The world is changing at an increasingly rapid pace. Dealing with this rapid rate of change is often about creating knowledge and making it available to be leveraged by team members. The PMO should take a central role in enterprise knowledge capture and availability.
Involving the PMO in the adoption of Scrum is required to meet the goal of delivering more business value faster. The PMO is central to the management of organization change in software product development. This responsibly is the charter for the PMO of the Future. Delivering more business value faster and the right business value is an enormous undertaking. Involving all the players and employing and enterprise view on top of the small team process of Scrum can dramatically change the pace and accuracy of business value delivery.
I would enjoy your comments and questions.
References and Reading
“Identifying Forces Driving PMO Changes” -PMI Project Management Journal, September 2010
[1] Mike Griffiths, PMP, ACP
