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
What are the roles and goals of the demand
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
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
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
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
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
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
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
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
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
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
Is this something every IT organization should
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.