Yum's shift to decentralized IT raises some interesting questions. After all, Bellinger has spent much of her tenure as CIO working to centralize IT for Pizza Hut, Taco Bell, KFC, A&W and Long John Silver's. Indeed, getting the restaurants working to the same set of IT standards has been part of her job since before they were spun off from PepsiCo in 1997. So after all that work, why would Yum reverse course and decentralize? More to the point, what does it mean to manage the transition from centralized IT to decentralized IT? Doesn't that just mean cutting loose business-unit CIOs so they can focus on their units' business needs rather than toe the line for central-IT bureaucracy?
No, it doesn't. Decentralization is not the reverse of centralization. Or if it is, you're doing something terribly wrong.
Centralization is relatively straightforward. The goals are clear: You want to implement standardized equipment and standardized procedures. You want to eliminate redundancies and variations. You want to reduce the costs that come with whatever is different by reducing the differences in how IT is used by your various business units.
That usually translates into company-wide IT standards, and all the bureaucratic overhead that comes with enforcing those standards. But centralization can result in real savings in equipment and support, along with the elimination of wasted effort.
On the other hand, decentralization isn't really about unwinding standardization and consistency. There's no point to that. No one wants to inject waste and get rid of savings. Nor is decentralization just about eliminating bureaucracy, especially when it has helped provide a clear, consistent IT vision for the whole company.
In fact, decentralization isn't really about the same things as centralization at all. It doesn't involve going in the opposite direction. It's really about turning IT inside out.
Consider one of the paradoxes involved in a move to decentralization: Business-unit CIOs must learn to be able to work independently, without always looking upstream for guidance.
But to get to that independence, they need--what else?--guidance. No magic switch exists to turn entire business-unit IT organizations into self-directing operations. There are new skills for CIOs to learn—and for CIOs to teach—because everyone in their IT shops will have to make the transition to decentralization, too.
In other words, the move to decentralized IT can't involve abandoning centralized leadership—at least not all at once.
The paradoxes don't stop there. Decentralized IT doesn't mean business units can just go their own way, ignoring everyone else. If they do, it's a costly mistake. Some of the most valuable resources for CIOs in a decentralized-IT situation are their fellow CIOs.
In part, that's because every business unit has its own technology needs. The more decentralized a business becomes, the more likely it is that each business unit will develop its own areas of expertise. So if one CIO needs to start figuring out social networking or cloud computing or PCI or iPhone apps, there's often a go-to guy among the other CIOs who has lots of useful experience in that specific area. Even if there isn't, the combined experience of fellow CIOs adds up.Yes, going to fellow CIOs is cheaper than hiring consultants. But they're not just domain experts. They also know the organizational culture and politics. Better still, they have the best interests of the business as a whole in mind. They know that what's good for another business unit is good for them. So comparing notes and trading expertise are in everyone's interest.
And that marks another paradoxical shift in decentralizing IT. Business-unit CIOs can't afford to become completely independent. They certainly don't want to find themselves competing against business units in the same corporate family. They need to shift from being a herd to being a pack, replacing top-down direction with cooperation and coordination among themselves.
One more paradox is usually a part of IT decentralization, and it's often a prelude to eventual re-centralization. It's not just some natural swing of the pendulum, where every few years the cycle begins again. There's always a reason for the shift.
Sometimes it's a matter of how business leadership sees IT. When IT is viewed as a cost center, centralization is used to cut costs. If leadership changes and IT is viewed as a platform for success, decentralization is used to make IT more nimble and flexible to deliver results for the business. When leadership changes again, it's back to centralized IT.
Other times, it's the economy. Recession? Business is bad. Cut costs. That means centralization. Expansion? Business is improving. It's time to chase new opportunities. That points to decentralization. Slowdown? Time to cut costs and centralize again.
Still other times, it's about organizational philosophy. IT centralization does lead to bureaucracy. That makes it hard for new initiatives to get going. The result: Splinter groups, skunkworks projects and under-the-radar practices tend to spring up in business units. The ones that don't work tend to die quickly (although it's often next to impossible to kill off a project or practice under centralized IT processes). The ones that do work look fresh, aggressive and laser-focused on the business-unit's needs.
Eventually, it comes to look like centralized IT is a huge drag on opportunity and decentralization is the right way to do nimble, effective IT. But with decentralization can come inefficiencies, unnecessary variation and duplicated effort--exactly the things that make centralization look like a much better choice. And the cycle begins again.
With that many potential reasons, a shift between centralized IT and decentralized IT is a lot less predictable than it might seem. It might be years away--or high on a new CEO's to-do list.
Maybe that means it's time for all CIOs to make sure the ability to manage transitions to both centralization and decentralization are in their skill sets. After all, if it's going to happen to you again and again, it's a good idea to know how to get it right every time around.