Mr. Lewis is a member of the GTA Board of Directors and a senior partner at the Edge Consulting Group. He served as chief information officer for Carnival Corporation, Six Continents Hotels, AT&T/Lucent Technologies and the Pratt & Whitney division of United Technologies. He also serves on the boards of directors of SoftBrands, Inc., and OpenWorld. He is a former board member of Leading the Way.
The following article first appeared in Computerworld magazine.
It's amazing to see companies swing back and forth between centralized and decentralized IT organizational models. Each swing of the pendulum features the firing of the CIO and the hiring of another. Each swing produces cataclysmic disruption and incredible productivity losses. I've seen one giant corporation go through five organizational swings and as many CIOs in six years.
So what triggers these organizational earthquakes, and how can you, as a CIO, avoid being a casualty?
Setting aside the more obvious triggers, such as botched ERP or CRM projects, one might assume that the CIO failed to align IT with the business or couldn't navigate in the company's executive ranks. Any $600-per-hour consultant could come up with a dozen reasons, but the most likely answer is that the company adopted a fatally flawed IT organizational model.
Adopt an IT governance model that doesn't fit the company, or omit a critical aspect of the model, and you're toast. The odds are against you. There are only three basic IT organizational models, and two of them fail consistently.
First, let's look at the two most prevalent -- and least successful -- models: centralized and decentralized. Each can be made to work, but only if it's an unusually good fit with the way the company is managed overall.
To illustrate the strengths and weaknesses in these two extreme models, let's use a fictitious company, Alpha Manufacturing Corp., and a fictitious CIO, Sue. I promise you, they spring from my real-life experiences.
Alpha Manufacturing has traditionally exercised strong corporate control over its
However, Alpha's business has eroded over the past two years, and the CEO, Alex, is demanding more revenue and profits from each region. The three regional executives band together to demand more control over the resources they need to make their new stretch targets. They claim that corporate IT is bureaucratic, inflexible, U.S.-centric, slow to respond to regional requirements and usually gets it all wrong when it does respond. The regional executives say the overhead burden needs to be slashed.
Alex hires the Pivot Consulting Group to come up with the fix for the problem. After six months of intense study, the consultancy's answer is to decentralize IT. Regional CIOs are hired, and each one launches an IT strategy for his part of the world. The corporate IT budget and resources are divvied up across the regions. Regional systems are deployed, and the "costly" central systems are turned off. With little left to justify her job, Sue leaves. With most of the regional IT budgets buried in multiple cost centers and with no financial oversight, it seems like IT costs have been dramatically slashed. Everyone is happy with the decentralized model.
Three years later, Alex is on the warpath. A Sarbanes-Oxley audit has exposed some serious problems. The corporate financial roll-up can't be reconciled with the company's 25 charts of accounts. No one knows exactly how many employees or contractors are in each region, much less the entire company. An attempt to reorganize the sales force by global customer accounts fails because the company can't find out what and how much it sells to each customer across the three regions. Each region has multiple product and customer codes -- and one has three order management systems. The audit exposes the existence of 23 different billing systems. Purchase orders can't be tied to contracts, and deliveries can't be tied to purchase orders. Regional executives show up at executive committee meetings with conflicting reports that are totally at odds with the chief financial officer's report. Embarrassingly, the audit uncovers what the regions are really spending on IT -- a total that's three times bigger than the centralized IT budget was five years ago.
Even though the regions are happy with their highly responsive IT organizations, Alex recalls Pivot Consulting to respond to the damaging audit. Its answer is to recentralize IT. Believe it or not, Sue is rehired. She quickly regains control of the regional IT resources and launches projects to consolidate billing systems, charts of accounts and product-fulfillment systems. The CIO racks up huge savings as data centers, global networks and call centers are consolidated. Everyone is happy, for now. Guess what's going to happen in about three years?
We've learned that centralized IT organizations are efficient in executing corporatewide initiatives and running stable, repetitive global operations. They excel at maintaining low unit costs, and their costs are visible and predictable. But they stumble when asked to be responsive to local requirements and they change direction slowly. Bureaucracy is their fatal flaw. The high visibility of the total IT budget makes costs easy to manage but presents an inviting target. Lack of responsiveness plus visible costs will trigger a swing back to a decentralized model.
Decentralized IT organizations are well aligned to business-unit strategies and are responsive to local requirements. They stay close to their customers and enjoy high satisfaction levels. Their costs are usually much higher than those of any other model but are embedded in the budgets of multiple business units and, thus, nearly invisible. Their autonomous nature makes corporatewide initiatives almost impossible. They tend to develop countless islands of data, so they're incapable of responding to headquarters' demands for integrated data reports. Once exposed, high costs and Balkanization of systems and data will trigger a swing to the centralized model.
The Hybrid Approach
Now, let's look at my favorite organizational structure, the hybrid governance model. The hybrid model brings together the best features of the centralized and decentralized models and avoids the extremes that often doom them. It uses a shared-services group to centralize functions that benefit from economies of scale and don't have to be highly agile. And it decentralizes functions that are close to the customer and have to be responsive to fast-changing market conditions and business-unit strategies. Usually, the decentralized IT group reports directly to the business-unit leader and, ultimately, to the CIO.
Data center operations, WANs, security, shared applications such as ERP and "plumbing" systems like e-mail are examples of functions that end up in the shared-services center. Maintenance, help desk operations and development of shared applications are handled by the shared-services group with heavy business-unit input. Centralizing these "big-ticket" functions yields major cost reductions. In this shared-services group, managers are driven to provide operational excellence at an ever-decreasing unit cost.
Meanwhile, LANs, regional help desks, engineering and manufacturing automation, facilities support and sales support are functions assigned to business-unit IT groups. As a rule, any function that isn't shared across several business units is a candidate for the business-unit IT group. The goal is maximum responsiveness and alignment with the business units -- even if costs increase. The added cost is more then covered by the savings produced by the shared-services center. The decentralized IT managers are driven to make their business units successful.
But even the hybrid model has a potentially fatal flaw, which lies in the interface between the shared-services group and the business-unit IT groups. Unless there's a clear set of specifications about roles and responsibilities, important stuff can get dropped or screwed up. Each side will make assumptions about who does what that are frequently wrong and can result in disasters. I call this set of rules the "governance document". Not flashy, but effective.
It's much more than a rule book. It describes the working relationships between individuals and groups, applications and networks -- and the company and its vendors. Most important, it describes how disputes will be handled and how the document will be kept pertinent to the tasks at hand. Done right, it's a living document used to operate the business of IT every day. I think it's the "secret sauce" of the hybrid model.
If your company is extremely centralized or extremely decentralized -- and you're feeling brave -- go ahead and adopt the matching IT organizational model. But if you want to be safe and possibly extend your career, adopt the hybrid model. It fits most businesses and accommodates change gracefully. But don't forget the secret sauce -- that all-important governance document.