The best way to manage IT projects is to eliminate them

Stop wasting time and effort on IT project portfolio management and start focusing on release management instead

1 2 Page 2
Page 2 of 2

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.

This story, "The best way to manage IT projects is to eliminate them," was originally published at InfoWorld.com. Read more of Bob Lewis' Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

Copyright © 2012 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
How to choose a low-code development platform