Why IT Executives Split Staffs to Create Supply, Handle Demand for Technology Services

IT is splitting up. It’s not petty squabbling that’s causing the breakup. No, this is a sign of maturity. CIOs in larger organizations are dividing their staffs into two major groups: one that negotiates with the business on IT strategy and IT project choices and manages the delivery of those projects (among other management consulting-type duties), and a second group that manages the infrastructure and delivers new applications (among other traditional tactical IT duties).

This trend of materially distinguishing demand from supply in IT is a grassroots phenomenon, rather than a coordinated response to consultants or guru-propagated wisdom, according to two McKinsey consultants.

“We were at a gathering of West Coast CIOs in 2006 talking about this and everybody looked around the room and said, ‘Hey, we’re actually doing this. We actually thought we were doing this on our own,’” says Diogo Rau, a McKinsey consultant. “People had different kinds of names for it: account managers, or relationship managers or business process owners. But somehow all these organizations were independently stumbling upon the idea of this new function whose role was to develop or to manage demand.”

We recently sat down with Rau and his colleague, David Mark, a director for McKinsey, to discuss this trend further.

CIO: Why must the management of IT demand be split off from supply?

David Mark: This is a part of a 10- to 15-year trend that we’re seeing. A lot of this started with the centralization of infrastructure services. Many companies have gone to a utility-type model for infrastructure and have been formalizing chargeback mechanisms. And that goes all the way back to the mainframe era.

The difference today is that you have the emergence of business processes. And as companies have tried to integrate business processes across different units and functions, we’re starting to see the same discipline that was applied to the lower level of the technology stack being applied to application development and business process. The split between demand and supply is being driven by a desire to get better economics or responsiveness out of resources that are shared.

What are the roles and goals of the demand unit?

DIOGO RAU: The first role the demand group plays emerges in the funding stage of projects. It focuses on portfolio management—helping decide what projects should be in your portfolio and making sure that you’re getting the maximum value out of them. The second role comes into play during the software development lifecycle, where the demand unit is acting as the business’s expert overseeing the supply organization as it builds software. The demand unit represents the business’s interests, much like a general contractor oversees the construction of a house.

Then there’s a third role around vendor management. So, the demand unit is not only managing project delivery, but it may be negotiating contracts with outside providers such as outsourcers and contract developers.

What about the supply organization?

MARK: The supply organization is where you will perform many of the traditional IT services such as the technical design, building, testing and deployment of applications. This is where all of your application developers are living, for example. In terms of structure, sometimes we find that the supply organization is a centralized group that serves the entire organization. In other cases, especially in large companies with diverse business units, it is [replicated across the organization to serve] specific business units. Regardless, it’s a good idea to separate demand and supply, even when the capabilities are not shared across multiple business units.

Let’s focus on the demand organization for a minute. When business units each have their own demand organizations, who should control them, IT or the business?

RAU: Let me make an analogy: The finance function often has controllers embedded within the business units. If the controllers have a solid line into the CFO, they can discharge their fiduciary responsibilities to the corporation overall while also helping their business units. In general, if you follow this same approach with IT, you can have these demand organizations report solid-line into the CIO and dotted-line to the business units and help make sure that no one is overspending on projects. In this way, the demand organization has some real power to control the budget.

MARK: You’d need a fair degree of maturity to have the dotted line be to the IT organization rather than to the business unit. Theoretically, once the demand and supply organizations are up and running, and the governance processes are mature and stable, you can imagine that eventually flipping around to consisting of a heavier tie to the business and a dotted line to the IT organization. But I don’t think we’ve seen that anywhere yet. And there’s a risk in that scenario, in which the relationship managers in the demand group may not necessarily have the kind of backbone they need. For example, they may not feel comfortable telling their business unit, “Hey, we should use this system that already exists in another business unit and extend it.” They may become more like order takers for their own business.

How about this scenario? Given that CIOs constantly complain about their huge project backloads, wouldn’t the demand units eventually get frustrated and say, “Forget it. I’m going to go outside and get someone else to do this.” Then the credibility of your supply organization—and by extension, IT in general—will suffer, won’t it?

MARK: If anything, splitting supply from demand helps with the overall planning because you gain more transparency and better clarity into what’s being demanded, what’s being supplied, and how well the supply side is functioning and interacting with the demand side.

But, of course, if the performance isn’t there, it will become more transparent under the split that we’re talking about, and it will highlight the issue.

RAU: If you can build this collection of demand organizations that have a strong value system and really work closely together, they should be able to make decisions that are in the best interest of the organization as a whole.

You say something revolutionary when you argue that IT should unequivocally own business process. What self-respecting businessperson is going to agree to that?

RAU: We do really see this trend that ownership of business process has been moving from something traditionally inside the COO organization, or other parts of the organization, into IT. Businesspeople are tired of their processes being broken and their IT not working right.

I often hear businesspeople say, “I’m the one who bought the SAP system, and I’m the one who’ll determine how it’s configured.” I sense a lot of reluctance on the part of the business—at least those that really care about IT—to give up the specification, or requirements, phase of IT.

RAU: We get a sense that there are certain parts of the workflow that the business may want to retain, but there are plenty of parts that they want to get rid of. And they don’t necessarily feel like they need to own the entire process end to end. I think this has been a huge problem for many IT organizations. Business process is a little bit of a red-headed stepchild. I mean, nobody knows exactly where or how to fit it into the governance model, or the development model, and it has tended to shift around a little bit in terms of ownership. And I think it’s a root cause of a lot of pain between business and IT.

MARK: System specification and implementation planning in business process are getting so welded together that you need a capability that is at a fairly detailed level to specify the business process, and then sync it into the technology plans that are being developed. So I think if you’re the head of sales and marketing, you’re clearly going to be involved in speccing out what your business imperatives are, what your high-level process looks like and how that marries to your objectives.

But then there’s the translation of that into the specific technical architecture, the components and the requirements that the business is willing to part with. I think putting it in the demand organization is actually a pretty attractive idea. It gives you sort of a natural home to weld those pieces together.

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.