The best way to manage IT projects is to eliminate them

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.

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.

Scrum takes every enhancement request and puts it in a queue, but instead of calling it the enhancements queue, which might confuse those who are easily flummoxed when someone calls something by its long-held, familiar name, it’s now known as the “backlog.” We should be happy about this, as it’s a rare case in which the new name is neither an acronym nor a more polysyllabic, harder-to-pronounce replacement for the old one.

In any event, every proposed change to an application goes into the backlog, listed as a “user story.” This is something else to like about scrum: User stories are the titles of yet-to-be-fleshed-out use cases, and again, the scrum vocabulary masters resisted the urge to create an intimidating name for them.

The way scrum works from here: Someone called the system owner (system “steward” would have been better) decides which user stories are to be worked on in the next “sprint,” an unintimidating word once again. A sprint is a short period of time — usually but not necessarily a month — that ends with a releasable build. What’s especially nice about scrum is that decisions about what goes into a sprint are actually a collaboration between the system owner and scrum team — a collaboration because the system owner defines the priorities, but the team knows how much work it can get done in a month.

No projects, no project portfolio management

Once we’ve eliminated all IT projects in favor of ongoing release management, there are no projects to evaluate, no master schedule, or any need for project portfolio management.

This doesn’t mean the enterprise no longer has priorities, or that it no longer has the means to control how it achieves them. What it means is that instead of implementing priorities through project portfolio management, the organization handles them by deciding how many developers to allocate to each major application in the IT applications portfolio.

The more developers assigned to an application, the faster it can change — I’m telling you this in case you couldn’t have figured it out on your own.

Why release management by itself isn’t good enough

If we were content to live with software delivery as IT’s endpoint, we’d be done now. But we aren’t because being done when the software meets requirements and adheres to specifications is what last-generation IT is about.

That’s one of the problems with scrum, in fact: While it might look new and snazzy from the perspective of someone accustomed to waterfall methodologies, it is, in fact, a new and snazzy way to do the same old stuff. Think of it as a Kevlar-and-titanium biplane. It’s a big improvement over balsawood and canvas, but it’s still a biplane.

In next-generation there are no IT projects. We’ve moved the goalposts, so the job isn’t finished until business change has happened.

Making that happen with scrum and release management calls for additional innovations. That’s where Theory of Constraints comes in, along with some nifty embellishments to scrum. But they won’t come in this week’s sprint — you’ll have to wait seven whole days for Advice Line’s next releasable build.