This vendor-written piece has been edited by Executive Networks Media to eliminate product promotion, but readers should note it will likely favour the submitter's approach.
One of the key functions of Project Portfolio Management (PPM) in IT is that of allocating finite funds to a subset of projects that vie for funding. When it works well, PPM becomes an effective agent of capital allocation within enterprise IT by funding promising projects and terminating underperforming ones. This is not very different to how a venture capitalist might manage their portfolio by investing in promising ventures and freezing funding or writing off investments in ventures that don't show promise.
Reforming PPM in Traditional Enterprise IT
How do IT portfolio managers know if a project X deserves to be funded over project Y? Traditionally, they have relied on the projections made in project business cases. Those that promise the greatest benefit (or threaten the gravest consequences of not being funded) usually win after a round of scrutiny. Of course, every once in a while, a project is automatically deemed eligible for funding because someone powerful thinks so.
How often are these funding decisions made? At the highest level, they are usually made once a year along with the budgeting cycle. Or they are made as and when projects come up for approval. Additionally, top-up funding decisions are made when a project runs out of funds earlier than planned. However, unlike the case of venture-capital, funding decisions in enterprise IT are rarely made on the basis of actual performance of projects. Funding beyond the first round isn't based on how well projects are delivering the benefits promised in the project business case. By and large, traditional enterprise IT has been more worried about delivering to plan and less about validating benefits.
Deliver Benefits, Not Scope
As long as the IT development organization is seen as a delivery organization, the responsibility of defining what to deliver rests solely with the business or with the product management organization. Separation of specifications from delivery also hurts the cause of true iterative development and undermines the ability to tweak the product based on learnings from development.
In this scheme of things, IT can't help but resign itself to attempting to deliver scope on plan. We can talk about benefits validation only when we move to a mode where IT solves problems rather than deliver scope. Benefits are realized when problems are verifiably solved.
The transition, however, from delivering scope to solving problems requires structural change. Typically, IT program and project management organizations worry about delivering scope on plan, while product management (or business) worries about solving problems. These two competencies need to work closer together for the transition to happen. Similar to the merger of development and operations advocated by DevOps we need a merger of product and delivery (ProDel?). Once we have cross-functional teams consisting of product and delivery people, we can turn our attention to the question of how to validate benefits now that we are set up to deliver benefits.
Sign up for CIO Asia eNewsletters.