Hybrid PMO – How to manage a hybrid project portfolio

As the use of Agile methods continue to grow and expand into various business sectors, more companies are facing new challenges that they had not experienced in the past. One such challenge is the evolution of a hybrid environment where the portfolio of projects encompasses a combination of traditional projects (managed by Waterfall process) and Agile models. This environment creates interesting challenges that must be overcome in order for organizations to maintain an adequate level of visibility and financial control, and to ensure there is accountability for successful outcomes of these investments.

In a traditional project portfolio, project reporting generally includes health and status of projects/programs using various metrics such as SPI (Schedule Performance Index), CPI (Cost Performance Index), and likely other dimensions such as financial health, resource utilization, resource availability, etc. Most Project Management Office (PMO) organizations are familiar with such metrics because they were established years ago and are well-understood by most senior executives and leaders who have been involved in project planning and execution. For projects that follow traditional/Waterfall methodology, this level of reporting provides an effective form of communication to project leaders who need to understand the progress of a project or program.

With the introduction of projects that do not follow the same process flow as traditional Waterfall projects, status tracking and reporting become much more difficult to manage, especially for PMO’s that have limited experience with program or portfolio management for incremental/iterative projects. In order to provide a cohesive, consolidated view of the entire portfolio to senior leaders, the PMO must ensure that all projects provide same (or similar) metrics. This means that the PMO must determine a strategy for defining key metrics such as SPI and CPI for Agile projects, which can be done in a number of different ways. The following will consist of a few possible options to consider to address this need.

Given that Agile projects typically do not have fixed scope, it is challenging to define a baseline for cost as well as schedule. While a traditional Waterfall project has fixed budget, fixed scope/requirements, and fixed schedule, Agile projects typically have a fixed cost and unknown schedule and scope, which often induces fear within PMO organizations. In order to streamline project reporting and communication, it is imperative that PMO’s align Agile projects to SPI and CPI, despite the challenges.

In order to streamline project reporting and communication, it is imperative that PMO’s align Agile projects to SPI and CPI, despite the challenges.

Cost for Agile projects is typically derived from labor, which means that funding should be determined based on anticipated labor effort and resource type. I believe that Agile projects should follow the same methodology as traditional projects during the proposal/initiation phase, when the project objectives and charter is defined. Once this has been completed, a staffing model can be defined using known information about the product or service that will be delivered. Then, the staffing model will be used to forecast average burn rate for the Agile project on a per-month basis; although most Agile teams will likely operate in sprints (or iterations) that span less than 1 month, determining a monthly cost will facilitate the determination of overall project budget.

As discussed, Agile projects do not have a fixed scope, so how do we derive the project scope which is necessary to forecast project duration? The key is to develop the project backlog (i.e. Product Backlog) and compile features based on the Project Charter and/or vision statement. Using input data points such as (1) Expected team velocity, (2) Team configuration, (3) High-level features, the project team can compile relative estimates on the features (i.e. Story Points), and use this data to forecast the total duration of the project based on the total work (number of Story Points) and the team velocity – the number of Story Points the team can complete within a period of time (per sprint). This enables the PMO to calculate the estimated cost for the project using monthly labor rate, which serves as the baseline for the CPI calculation.

Once the baseline cost and schedule has been established using the approach described, as the development and delivery of ​features begins, progress is tracked against original baseline (in units of Story Points); this progress will be reflected in the SPI metric. Similarly, if the features take longer than expected, the increased cost will be reflected in the CPI as more sprints are required to complete the work.

The benefit of following an Agile model for project execution is maximized in a cost-sensitive environment; if actual project cost has reached the original budgeted allowance, the project sponsor can decide to close the project, but still obtain functional, tested, valuable capabilities that can either be released to the market (or user community), or be used as the foundation for a future project. This situation is very different from a traditional project, where cost or schedule delays usually result in project cancellation without any tangible value being delivered. This is the biggest difference between the traditional Waterfall approach and the Agile, iterative method.

By aligning Agile and traditional projects in terms of health tracking and reporting, PMO’s gain the ability to provide a consolidated view into the entire project portfolio, which enables the organization to manage their investments in an effective way.

Eugene Lai