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.
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.
Sign up for Computerworld eNewsletters.