It sounds like what you're really talking about is creating an organization specifically for the requirements phase of traditional software projects. Why can't IT just do that without splitting itself up?

MARK: I think you're absolutely right that a big part of this is requirements definition, which is a piece that's sorely needed. But there are at least two other skills that we're talking about here. One is portfolio management and acting with fiduciary responsibility to the entire organization to make sure that your IT dollars are well spent. And then there's another piece around vendor management.

How does enterprise architecture and SOA fit into this? Is this a job for the demand group as well?

MARK: My bias would be to put that inside the supply organization. The demand organization certainly would know all about SOA, but there is probably no need to communicate that to the business or for the demand group to own it itself.

What's the hard ROI of doing this?

RAU: The benefits are very hard to quantify, but they are big. If you look at portfolio management, what's the value of investing only in projects that have the best benefits? You are essentially upping the ROI on all of your individual projects, and not funding some projects that might have cost you a lot of money.

Secondly, when you look at the requirements definition piece, the demand organization is really rationalizing the demand at a requirement level. They look at individual features and ask: "Do you really need all of that?" Again, the benefits are hard to quantify, but they're there.

And then if you consider vendor management, you'd almost certainly benefit from having someone who acts as a better manager of your supply organizations.

OK. Say a CIO wants to do this. What are some key metrics that he should keep in mind as he goes through this transition?

MARK: The metrics aren't particularly new, but an important one is the percentage of projects that have good business cases behind them and well-defined methodologies. Another is the on-time and on-budget performance of the project delivery organizations. Another one is comparing the ROI you predicted at the beginning of the initiative to what you actually receive.

Is this something every IT organization should consider doing?

RAU: It's not a foregone conclusion that you need to do this in all cases. If, for example, your IT strategy is to be super agile and develop new products as quickly as possible, you might have a structure that is much more decentralized. Or if you are focusing purely on cost, you might want to go to an organization where everything's centralized into one group. And in very small companies, you probably wouldn't want to go to this kind of a structure. You might set up mechanisms that mirror it within an organization, but you really wouldn't want to create two separate groups.

But we do think that splitting demand from supply helps to improve business delivery of IT. It's like a tidal force. You can swim against it, but ultimately the vast majority of companies are going to end up with much more formal relationships between demand and supply.