For next-generation IT, the state-of-the-art for project portfolio management might very well be eliminating project portfolio management altogether. It's possible, and in many cases highly desirable, to organize the flow so that the subject never comes up.
But there's a big asterisk attached to this -- namely, while many businesses have implemented each of the bits and pieces needed for the elimination of project portfolio management to work, it's hard to find any that have put all the pieces together. (If you work in one of them, I'd love to talk to you about it -- call me!) The key pieces? Release management, scrum, Goldratt's Theory of Constraints (TOC), and the recognition that there are no IT projects.
[ Find out the 10 business skills every IT pro must master, beware the 9 warning signs of bad IT architecture, and steer clear of the 12 "best practices" IT should avoid at all costs. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line newsletter. ]
There are a lot of moving parts to this change. We'll take on the first two this week and the rest next week.
Release management: The merging of two streams
By itself, this is straightforward: Rather than organize IT work into projects, organize IT work by system, with changes broken down into scheduled releases. In a typical waterfall environment, where business managers expect to wait months for projects to complete, monthly releases ought to be a delightful level of acceleration.
Better yet, this solves a thorny staffing problem. Every CIO knows there are never enough good project managers to go around. Project management is a tough, demanding discipline that calls for an unusual combination of skills, aptitudes, and character traits.
Sadly for the profession but happily for the CIOs who don't have enough project managers, moving away from projects in favor of releases and a release plan eliminates this staffing bottleneck because a key characteristic of releases is that they bundle up a collection of enhancements and bug fixes. Whatever is ready goes in, whatever isn't ready is held for the next release, and no one system change is big enough to need any project management.
The good and the bad about making this shift from projects to releases is that it merges two streams of system requirements: those from the traditional enhancements queue and those that would otherwise have been handled by a project. The bad part is that evaluating the relative importance of enhancements has little to do with how a project team typically maps out the optimal order in which to build or modify modules to achieve a major system change.
The good part is that one way or another, they're merged into the system regardless. Merging them into a single stream of work provides a fine-grained way to adjust the pace of both queues on a month-to-month basis.
The question is how you go about it. One answer, and a good one at that, is scrum.
Scrum isn't project management
In case you've been doing your best to ignore everything related to agile, scrum appears to be the most widely adopted agile variant -- at the moment. Regardless of whether you've been ignoring it, the most important thing to know is that in spite of what you may have read, scrum has nothing to do with project management. It isn't a new way to manage projects, an old way to manage projects, a new twist on an old way, or anything like that.
Scrum is a release management methodology. It provides a way to manage the enhancements queue -- no more, no less. It's a good way to manage the enhancements queue, too.