There’s this myth pervading the portfolio management space that there’s a single benefit measurement model to rule them all. Whether it be NPV, ROI, IRR, user satisfaction surveys or any other measure of tangible benefits, the reality is that any project may be measured according to any number of benefit measurement models stretching in a spectrum from the tracking of objective data to subjective data.
The trick is to identify the project type, and map that project type to an appropriate benefit measurement model. For example, an IT project to support a specific application may be designed to reduce down time, to enhance user satisfaction, or to increase the speed of operations. Each of those benefits are measurable, insofar as they can be assessed through service metrics or satisfaction surveys.
The challenge, however, is that oftentimes we have never implemented the monitoring systems to track these metrics – despite the fact that they’re in the gospel of ITIL as part of Service Design. Hence, if we want to track against these metrics, we need to incorporate the creation of the baseline and tracking system into the budget of the project.
A PMO can slip that monitoring into the budget of one project, but sooner or later, sheer inertia negates this, as the stakeholders begin to rebel against repeatedly approving extra budget for monitoring project success. Due to simple budgeting constraints, we can’t incorporate a metrics monitoring system on the front end of every project. From a logistical standpoint, this won’t work as well, as it typically takes a fair amount of time to build up meaningful performance baseline data, and by the time we put everything on pause to collect this data, the project would have slipped far past the most forgiving stakeholder deadline.
The solution is not to incorporate metrics tracking into every project that passes through the approval process, but as the front end design of every program that passes through our portfolio. If we treat an application as a program, we can set a threshold, i.e. any application with X number of users or that we will use for longer than Y years will need a metrics tracking system incorporated into the program design. The metrics tracking system will generate performance data to assess if we are hitting our service performance goals, and our financial goals.
Those metrics then become the performance metrics for every project that is incorporated into the program. This gives us another answer to the question of how we define programs within our portfolio. A program is a framework for benefits measurement that may applied to the projects that reside within the program.
This also makes our investment decisions easier as we can budget to the program, and then allow the metrics within the program to dictate the actual composition of projects within the program. How to assess the value of the program? By identifying how it ties into the overall operations of the company – which is far easier than doing so at the project level.
Taking this concept one more level, a properly designed program should be tied to ongoing business conditions. A periodic assessment should be conducted of the business environment to confirm that the program itself remains viable based on certain predefined measures of program success. When the business conditions change, the program funding spigot can be turned off, effectively killing all projects within that program. Alternately, additional funding can be added to the program, which in turn is directed to the proposed projects that meet the programmatic success measures.