IT is splitting up. It\u2019s not petty squabbling\n that\u2019s causing the breakup. No, this is a sign of\n maturity. CIOs in larger organizations are dividing their\n staffs into two major groups: one that negotiates with the\n business on IT strategy and IT project choices and manages the\n delivery of those projects (among other management\n consulting-type duties), and a second group that manages the\n infrastructure and delivers new applications (among other\n traditional tactical IT duties).This trend of materially distinguishing demand from supply\n in IT is a grassroots phenomenon, rather than a coordinated\n response to consultants or guru-propagated wisdom, according to\n two McKinsey consultants.\u201cWe were at a gathering of West Coast CIOs in 2006\n talking about this and everybody looked around the room and\n said, \u2018Hey, we\u2019re actually doing this. We actually\n thought we were doing this on our own,\u2019\u201d says Diogo\n Rau, a McKinsey consultant. \u201cPeople had different kinds\n of names for it: account managers, or relationship managers or\n business process owners. But somehow all these organizations\n were independently stumbling upon the idea of this new function\n whose role was to develop or to manage demand.\u201dWe recently sat down with Rau and his colleague, David Mark,\n a director for McKinsey, to discuss this trend further.CIO: Why must the management of IT demand be split\n off from supply?David Mark: This is a part of a 10- to\n 15-year trend that we\u2019re seeing. A lot of this started\n with the centralization of infrastructure services. Many\n companies have gone to a utility-type model for infrastructure\n and have been formalizing chargeback mechanisms. And that goes\n all the way back to the mainframe era.The difference today is that you have the emergence of\n business processes. And as companies have tried to integrate\n business processes across different units and functions,\n we\u2019re starting to see the same discipline that was\n applied to the lower level of the technology stack being\n applied to application development and business process. The\n split between demand and supply is being driven by a desire to\n get better economics or responsiveness out of resources that\n are shared.What are the roles and goals of the demand\n unit?DIOGO RAU: The first role the demand group\n plays emerges in the funding stage of projects. It focuses on\n portfolio management\u2014helping decide what projects should\n be in your portfolio and making sure that you\u2019re getting\n the maximum value out of them. The second role comes into play\n during the software development lifecycle, where the demand\n unit is acting as the business\u2019s expert overseeing the\n supply organization as it builds software. The demand unit\n represents the business\u2019s interests, much like a general\n contractor oversees the construction of a house.Then there\u2019s a third role around vendor management.\n So, the demand unit is not only managing project delivery, but\n it may be negotiating contracts with outside providers such as\n outsourcers and contract developers.What about the supply organization?MARK: The supply organization is where you will perform many\n of the traditional IT services such as the technical design,\n building, testing and deployment of applications. This is where\n all of your application developers are living, for example. In\n terms of structure, sometimes we find that the supply\n organization is a centralized group that serves the entire\n organization. In other cases, especially in large companies\n with diverse business units, it is [replicated across the\n organization to serve] specific business units. Regardless,\n it\u2019s a good idea to separate demand and supply, even when\n the capabilities are not shared across multiple business\n units.Let\u2019s focus on the demand organization for a\n minute. When business units each have their own demand\n organizations, who should control them, IT or the\n business?RAU: Let me make an analogy: The finance function often has\n controllers embedded within the business units. If the\n controllers have a solid line into the CFO, they can discharge\n their fiduciary responsibilities to the corporation overall\n while also helping their business units. In general, if you\n follow this same approach with IT, you can have these demand\n organizations report solid-line into the CIO and dotted-line to\n the business units and help make sure that no one is\n overspending on projects. In this way, the demand organization\n has some real power to control the budget.MARK: You\u2019d need a fair degree of maturity to have the\n dotted line be to the IT organization rather than to the\n business unit. Theoretically, once the demand and supply\n organizations are up and running, and the governance processes\n are mature and stable, you can imagine that eventually flipping\n around to consisting of a heavier tie to the business and a\n dotted line to the IT organization. But I don\u2019t think\n we\u2019ve seen that anywhere yet. And there\u2019s a risk in\n that scenario, in which the relationship managers in the demand\n group may not necessarily have the kind of backbone they need.\n For example, they may not feel comfortable telling their\n business unit, \u201cHey, we should use this system that\n already exists in another business unit and extend it.\u201d\n They may become more like order takers for their own\n business.How about this scenario? Given that CIOs constantly\n complain about their huge project backloads, wouldn\u2019t the\n demand units eventually get frustrated and say, \u201cForget\n it. I\u2019m going to go outside and get someone else to do\n this.\u201d Then the credibility of your supply\n organization\u2014and by extension, IT in general\u2014will\n suffer, won\u2019t it?MARK: If anything, splitting supply from demand helps with\n the overall planning because you gain more transparency and\n better clarity into what\u2019s being demanded, what\u2019s\n being supplied, and how well the supply side is functioning and\n interacting with the demand side.But, of course, if the performance isn\u2019t there, it\n will become more transparent under the split that we\u2019re\n talking about, and it will highlight the issue.RAU: If you can build this collection of demand\n organizations that have a strong value system and really work\n closely together, they should be able to make decisions that\n are in the best interest of the organization as a whole.You say something revolutionary when you argue that\n IT should unequivocally own business process. What\n self-respecting businessperson is going to agree to\n that?RAU: We do really see this trend that ownership of business\n process has been moving from something traditionally inside the\n COO organization, or other parts of the organization, into IT.\n Businesspeople are tired of their processes being broken and\n their IT not working right.I often hear businesspeople say, \u201cI\u2019m\n the one who bought the SAP system, and I\u2019m the one\n who\u2019ll determine how it\u2019s configured.\u201d I\n sense a lot of reluctance on the part of the business\u2014at\n least those that really care about IT\u2014to give up the\n specification, or requirements, phase of IT.RAU: We get a sense that there are certain parts of the\n workflow that the business may want to retain, but there are\n plenty of parts that they want to get rid of. And they\n don\u2019t necessarily feel like they need to own the entire\n process end to end. I think this has been a huge problem for\n many IT organizations. Business process is a little bit of a\n red-headed stepchild. I mean, nobody knows exactly where or how\n to fit it into the governance model, or the development model,\n and it has tended to shift around a little bit in terms of\n ownership. And I think it\u2019s a root cause of a lot of pain\n between business and IT.MARK: System specification and implementation planning in\n business process are getting so welded together that you need a\n capability that is at a fairly detailed level to specify the\n business process, and then sync it into the technology plans\n that are being developed. So I think if you\u2019re the head\n of sales and marketing, you\u2019re clearly going to be\n involved in speccing out what your business imperatives are,\n what your high-level process looks like and how that marries to\n your objectives.But then there\u2019s the translation of that into the\n specific technical architecture, the components and the\n requirements that the business is willing to part with. I think\n putting it in the demand organization is actually a pretty\n attractive idea. It gives you sort of a natural home to weld\n those pieces together.It sounds like what you\u2019re really talking\n about is creating an organization specifically for the\n requirements phase of traditional software projects. Why\n can\u2019t IT just do that without splitting itself\n up?MARK: I think you\u2019re absolutely right that a big part\n of this is requirements definition, which is a piece\n that\u2019s sorely needed. But there are at least two other\n skills that we\u2019re talking about here. One is portfolio\n management and acting with fiduciary responsibility to the\n entire organization to make sure that your IT dollars are well\n spent. And then there\u2019s another piece around vendor\n management.How does enterprise architecture and SOA fit into\n this? Is this a job for the demand group as well?MARK: My bias would be to put that inside the supply\n organization. The demand organization certainly would know all\n about SOA, but there is probably no need to communicate that to\n the business or for the demand group to own it itself.What\u2019s the hard ROI of doing\n this?RAU: The benefits are very hard to quantify, but they are\n big. If you look at portfolio management, what\u2019s the\n value of investing only in projects that have the best\n benefits? You are essentially upping the ROI on all of your\n individual projects, and not funding some projects that might\n have cost you a lot of money.Secondly, when you look at the requirements definition\n piece, the demand organization is really rationalizing the\n demand at a requirement level. They look at individual features\n and ask, \u201cDo you really need all of that?\u201d Again,\n the benefits are hard to quantify, but they\u2019re there.And then if you consider vendor management, you\u2019d\n almost certainly benefit from having someone who acts as a\n better manager of your supply organizations.OK. Say a CIO wants to do this. What are some key\n metrics that he should keep in mind as he goes through this\n transition?MARK: The metrics aren\u2019t particularly new, but an\n important one is the percentage of projects that have good\n business cases behind them and well-defined methodologies.\n Another is the on-time and on-budget performance of the project\n delivery organizations. Another one is comparing the ROI you\n predicted at the beginning of the initiative to what you\n actually receive.Is this something every IT organization should\n consider doing?RAU: It\u2019s not a foregone conclusion that you need to\n do this in all cases. If, for example, your IT strategy is to\n be super agile and develop new products as quickly as possible,\n you might have a structure that is much more decentralized. Or\n if you are focusing purely on cost, you might want to go to an\n organization where everything\u2019s centralized into one\n group. And in very small companies, you probably wouldn\u2019t\n want to go to this kind of a structure. You might set up\n mechanisms that mirror it within an organization, but you\n really wouldn\u2019t want to create two separate groups.But we do think that splitting demand from supply helps to\n improve business delivery of IT. It\u2019s like a tidal force.\n You can swim against it, but ultimately the vast majority of\n companies are going to end up with much more formal\n relationships between demand and supply.