Putting one foot in front of the other (part 1)

In the last post, I suggested some of the fundamental, structural changes I think IT will have to undergo in the next 10-15 years. And to me, these changes are not optional: organizations will have to make them; the only question is who will risk the difficulties and step up to lead them (and reap the substantial rewards)?

With that done, I want to come back to Earth a bit, and kick off a series of more modest posts that look at some of the baby steps IT needs to take to evolve into a truly strategic capability.

To me, once an IT leader adopts the correct orientation of her department as a strategic asset primarily focused on delivering business value (rather than IT capabilities), she has  a number of very tactical areas to address:

  1. Demand pipeline
  2. Structured requirements
  3. Developer-heavy staffing
  4. Agile methods/approaches
  5. Service catalog
  6. Portfolio management (including rationalization)

In this post, we’ll take a look at the first, demand pipeline.

#1. Demand Pipeline

Just about the biggest problem IT shops have is managing their demand pipeline. Use whatever trite metaphor you like (short order cooks, throwing projects over the wall, etc.), the reality is that most IT departments are at the mercy of their demand pipeline.

This is true whether you have no control (the business expects you to say yes to everything, uses “phone a friend” to get all their requests through, and so on) or total control (nothing gets on the schedule unless it passes a rigorous and incomprehensible phase gate process)—in the end, tremendous amounts of time and energy are spent tackling too many requests or fending them off…and little time is spent focused on evaluating the pipeline to determine how each project delivers tangible business value.

When the rubber hits the road, managing the demand pipeline shouldn’t be an isolated activity concerned with giving IT the breathing room to keep the lights on, but rather part of the larger strategic portfolio management process (which we’ll get to later in area #6).

You have to fix the pipeline problem at the C-level, because the responsibility for aligning the demand pipeline with the strategic best interests of the organization is neither solely a business nor an IT responsibility. Rather, both must come together around the business functions IT supports (operations, product development, business process engineering, marketing, customer communications, project management, and quality control) to prioritize the work the organization can do (with IT’s leadership) to further these goals.

What doesn’t work is assigning mid-level business and IT managers to the problem, giving them the authority to set up project portfolio review committees, and tasking them with “solving” the IT demand pipeline problem. This is like US automakers putting out cars like the Mercury Comet and AMC Pacer in the 1970s to compete with the success of cars like the Toyota Celica and Honda Civic CVCC—it attacks a symptom not a root cause and ultimately fails….after wasting a tremendous amount of time and energy.

In the next post we’ll turn to structured requirements, which, like the demand pipeline, can be approached in a strategic, enterprise way to transform IT.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: