The choice between centralized and embedded IT is not an all or nothing decision. In this blog, Patrick Gray explains why.
For nearly as long as CIOs have been talking about concepts like alignment, there has been a debate in IT about whether it should be a centralized, monolithic corporate organization or be "embedded" in each business unit and reported to whoever manages that business unit. Proponents of the centralized IT organization contend that it is the most cost-effective model, essentially saying that embedded IT organizations will create duplicated efforts and a hodgepodge of different systems across the company that rarely integrate with each other.
Advocates of the distributed model suggest that an embedded IT function will not only be more responsive but also be more of an expert in that particular business function. The assumption is that if all you do is marketing-related IT activities, you will probably be more marketing-savvy than an IT generalist. Embedded IT proponents also see it as a way of avoiding budgetary arguments. If sales wants a new system and builds it with its embedded personnel, there is no question of where the budget comes from or whether the project will be managed in sales' best interest.
Like too many political debates, proponents of either of these IT management philosophies find themselves defending their "camp" against all who oppose it, rather than recognizing that good ideas come from each side and that this need not be a binary decision. In terms of building the most effective hybrid organization, I suggest centralizing IT infrastructure and utility functions, while building project teams from and embedded in business units.
Centralize infrastructure with "customer" friendly management
Few will argue that each business unit needs something like its own e-mail system and the associated maintenance overhead, and these types of generic services are perfect candidates for centralization. These commodity functions also nicely fit into the various frameworks du jour for IT management, as they can be managed based on cost and service levels, and internal employees are effectively the target market. The central body that maintains these commodity services can also look to outsourcing, cloud computing, or any number of different ways to cut costs while maintaining the same quality of service as necessary, since the backend can and should be transparent to the consumers of this organization's services.
While I generally rail against IT taking the mind-set that internal employees should be referred to as "the customer," in this paradigm it is appropriate. This central infrastructure body should be able to flexibly allocate computing resources to its customers (internal business units) in the most cost effective and flexible manner possible and, like any other utility, come on like the light switch without a second thought. Most IT organizations are fairly successful at managing a central infrastructure component. Where they break down, however, is in project-focused activities.
Embed the project teams
Where the rubber meets the road for corporate IT is an ability to execute relevant, timely projects that help implement the corporate strategy. These projects are usually highly visible, and the ones that the CIO and his or her IT organization is most likely to be judged upon. While these projects generally involve complex technologies, understanding the strategic, tactical, and operating decisions that drive the project are equally critical to the outcome. These are the types of projects that need to be managed with more of a consultative approach and need to have everyone working in the best interests of the real customer: the person or business with check in hand that buys the company's products and services.
Whereas for infrastructure-related activities, an IT person's presence is usually indicative of something gone amiss, a project team where IT sits on one side of the building and "the business" sits on the other is a sure sign of something gone terribly wrong.
There are two very different types of people with very different skill sets who tend to excel in each of these environments, and one critical mistake of many IT organizations is a feeling that people can be interchanged between the two. While there is no prohibition against moving people to where they can be most successful, dropping an excellent technician into a project leadership role or a business-savvy "fast talker" into a technical role may backfire.
Both groups also require different management philosophies, and arguably the CIO should allocate the most focus to project-related activities and use the infrastructure side of the house as a proving ground for young leaders, allowing them to manage an infrastructure-related function with near-complete autonomy. Realizing that the choice between centralized and embedded IT is not an all-or-nothing decision may not only be liberating but will likely make your IT organization more flexible and all the more valuable to the organization as a whole.