Project portfolio management (PPM) vendors promise to help customers juggle competing investment priorities, reduce IT failures, and improve alignment between technology and their business. Given these impressive benefits, it's worth examining what's required to successfully implement PPM. To learn more about the issues, I attended a PPM briefing by HP.
Dennis Gaughan, Research Director at AMR and one of the HP presenters, is an expert on the PPM market. In an interview, he described PPM success factors:
PPM deployments are no different from any other transformational exercise which is driven from the top down. The CIO must be the executive champion for these deployments. It's also important to establish a PMO, so you have a centralized point for aggregation of data and control.
When implementing PPM, start with the question, "How good are you at delivering today?" To gain business support, IT must demonstrate it is capable of delivering and executing IT project successfully. Credibility with the business is a key issue. If you haven't had a good track record delivering from an IT perspective, it will be hard to get the level of business commitment required to be successful with PPM.
Dennis offered advice for making PPM implementations successful:
As Dennis told me, many organizations overlook the importance of measuring benefits on a post-mortem basis:
PPM involves upfront standardization of criteria used for building business cases and metrics. However, people don't always go back to evaluate and measure, after the fact, whether they realized those results. When used this way, PPM can measure overall IT effectiveness, in effect answering the question, "How good are we at delivering value from technology?" Instituting this discipline is the challenge.
I asked Jon Collins, Service Director at Freeform Dynamics, a UK-based analyst firm, and co-author of "The Technology Garden," to comment on the intersection of IT and business with respect to PPM, especially from a project failures perspective:
Project portfolio management involves a number of activities, the most basic of which is “to get everything into one place.” That helicopter view onto a number of projects is a major step forward for a program manager, IT exec or CIO, as it is often the dependencies between projects that cause failure; equally – and we have all seen this happen – projects may continue long after the initial requirement has changed, or even gone away.
To be successful, PPM requires someone who is actually capable of collating the right information and interpreting it in a way that enables a good steer through pitfalls of project implementation. Good program managers are hard to come by, but in my experience a high quality person at the helm can overcome poor organizational processes, whereas the best processes can fail if the person in charge doesn’t know how to steer the ship. One can become a slave to project metrics.
Here's a relevant quote, included in our book, from Darin Brumby, CIO at First Group: “In my portfolio I have 220 projects . . . Sure, I’d like Utopian projects which all finish on time and to budget, all highly successful deployments with great post-implementation reviews. In reality I would be happy if just 80% of those just moved along, and were completed. Even if they were just 80% right, I would be happy because the amount of distance that would move this company forward against its competitors in this sector would be enormous.”
THE PROJECT FAILURES ANALYSIS
Despite PPM's clear benefits, it's neither a panacea nor is it appropriate for every organization. Before implementing any PPM system, ask yourself three questions (and be honest when you answer):
If you answered "yes" to these questions, PPM may be a great vehicle for building real partnership between the technology and business sides of your enterprise. If you answered "no," then perhaps it's time for your organization to take a look in its collective mirror and make some changes.