Understand and control the centralization cycle

One of the most consistent systems I’ve discovered moving from organization to organization is the "centralization cycle.” Companies move from highly centralized to highly decentralized IT organizational models, sometimes consciously, but often as a result of political forces. I’ve worked with CIOs struggling to keep their centralized models together, and with regional IT managers trying to break apart unresponsive monolithic organizations. No matter what part of the cycle you are on, it’s easy to get lost in the political, social, and organizational struggles and lose sight of the big picture.
From a participant's view, the cycle looks like a giant political and budgetary struggle. Egos and vested interests collide in a battle for political capital. Employees tremble as the great forces in their organizations confront one another, rewriting budgetary authority and lines of management. Or they cynically watch, well aware that this time next year everything will be rewritten again.
From an outsider's perspective, things are a bit less chaotic. In fact, despite the formal statements of various organizations there seems to be a natural cycle at work forcing the change. Different companies have different rhythms; one organization I worked with changed every five years, one every 10, and another every two—and each company's cycle was fairly regular. That last one had some of the most stressed employees I've ever encountered. But though the staff changed, sometimes radically, something held the company on a steady course.
Sources of the cycle
Since the cycles had predictable intervals, each company involved had to have some kind of consistent, guiding influences that set the context. Given the personal nature of the struggles, I strongly doubted that it tied to either a vision statement or other changeable business artifact.
When the revelation came to me, I was between jobs, so I took a bit of time to do research. What I discovered seemed obvious in retrospect.The most important factor in many companies’ centralization cycle was the business cycle of their market. It seemed to vary, however, whether a company centralized or decentralized during good times. Companies in multiple markets tended towards an average cycle, with different divisions centralizing and decentralizing at different rates.
The next most important factor was how credit for profit is allocated. IT (by its nature) rarely shares in the credit for business success but also correspondingly avoids the blame for failures. When there are few failures but many successes, credit accumulates in the extremities. When there are failures, that credit is expended, allowing the IT department to wrest control of budgets away from the outside factors. If, however, the IT department is organizationally the scapegoat for problems, it correspondingly gains in power when things go well.
Another guiding factor was how quickly the organization adopted changes. The easiest measurement for this came from the identification of new "change initiatives" and how deeply they affected the company. Companies whose management embraced change, but with very conservative structures, changed slowly. Less conservative cultures changed more quickly, whether the management wanted them to or not. In this case, IT centralization was just one of a host of changing systems, oscillating along with the rest of the organization.
The final factor I found, although it was present in only a few of my clients, was in the internal promotion systems. In those organizations where people could be promoted to central IT from the local organizations, the transition from centralized to localized IT seemed to carry much fewer ramifications. In these organizations the "transition" was largely a matter of budgetary chest beating; the actual decision making occurred through much more cooperative informal channels.
Turning this to our advantage
Other than pure sociological interest, what does this kind of analysis tell us? Does it suggest ways we can tune our organizations? Provide us with a unique tool for preserving the power of centralized IT despite whatever pressures might override us? Or are we doomed to forever writhe in the hands of a cycle we can’t control, taking credit and accepting blame for things that really have nothing to do with us?
The first thing it does is allow us to achieve some perspective on our situations. Although the losses and gains may feel distinctly personal, they are also part of a larger system of behavior within the organization. We can use this information to set aside our egos and address what our organization needs, not what we want.
The idea that centralization is a cycle also allows us to logically consider whether what we want meshes with the cycle of activity. Trying to push for centralization during a decentralization phase of the cycle may simply be burning political capital for no gain. If the forces at work are large enough (like a combination of corporate organization and market cycles) we can easily find ourselves ground underfoot. Rather than pushing for full centralization in such times, we need to concentrate our resources on protecting our "key features"—whatever it is that provides our particular IT organization with the highest ROI.
Finally, the idea that we are dealing with a cycle allows us to investigate the factors in that cycle in our own organizations. If we can work out the factors influencing the transition, we can more accurately focus our efforts. This allows us to step back from the limited arguments about a particular project or budget and focus on changing the influences themselves. In some cases (like a market cycle), we have no real control over the influence. In others (like promotion policy or organizational culture), we may have more influence than we think.
By formalizing and researching the idea of a cycle for IT centralization, we provide ourselves with a theoretical tool to help with our overall strategy for our organizations. We also create a context in which we can think about specific initiatives in terms of their applicability.