More from Susan Cramm on IT. This time it’s the issue of centralized vs. decentralized control of IT projects. The point: you can have both, but in different aspects of IT. Decentralize what services are provided but centralize how they are provided.
When leaders think about reorganizing IT, they usually start with the assumption that they have two options: To centralize or to decentralize. Of course, in the real world, marketplaces are too complicated and nuanced to be served by one or the other of these two extremes. Organizations architected to run like either a central Soviet economy or a volunteer cooperative are destined to fail.
It’s possible to break through this binary thinking by approaching organizational design differently. Instead of starting by deciding on a structure, you can start by deciding who gets to make what IT decisions. If done right, you can get the best of both worlds: In effect, decentralized centralization.
Let’s use a real-world example to illustrate. Reader Brent shared in his post that he is “in the process of a leading a major organization change program to create a centralized IT function in an organization that currently has a decentralized IT function.” Brent’s story is prototypical. The decision to centralize was spurred by “no sharing of best practices, no centralized view of spend, patchy commercial relationships with vendors, and a high rate of failed projects.”
But Brent’s company doesn’t have to throw the whole IT organization into a blender to address these issues, because the issues he lists aren’t actually structural issues. They’re issues that arise from a missing or incorrect decision rights.
Decisions rights define who makes what decisions about IT. In allocating rights, a loose rule of thumb is that line managers should have authority over what services are delivered and IT should have authority over how the services are delivered.
What Brent really wants is a centralized view of spend but decentralized accountability for that spending. He can do this by creating a financial coordinator position that implements processes and tools that allow a single view into accounting (how services are delivered) while leaving the investment decision in the hands of line managers (what services are delivered) and the cost management in the hands of the local IT managers (how services are delivered).
And the beautiful thing about starting with decisions rights instead of blowing up org charts is that Brent can mix the centralized and decentralized decision rights without having to enter the complex and costly process of revamping the company’s structure.
This works because processes impact organizational behavior more than structure. Who people work with is more important than who they work for. And changing the latter doesn’t necessarily change the former.
If structural changes are made at all, they should be applied with a light hand as a finishing touch to the revamping of decisions rights. Those structure changes should be made to serve three goals: strengthen decision rights, streamline processes and gain efficiencies, and accelerate skill development.
Most IT organizations have decided to centralize decision rights related to infrastructure services in order to capture economies of scale. But while the decision rights are centralized, the IT resources don’t have to be. For example, a company may have a single decision making point for investing and building out its call center, but the call center organization may still consist of decentralized personnel working from their homes and having decision rights over maintaining their systems.
Furthermore, IT solutions delivery (e.g., relationship management and applications delivery) organizations should mirror the structure of the business. Therefore, if it reflects how his business is organized, Brent may want leave solutions delivery resources decentralized but centralize reporting relationships to reinforce desired changes in practices.
However he approaches it, I hope Brent can convince his company that it’s time to kill off this centralized versus decentralized IT debate. No longer should we ask, “Should we centralize or decentralize IT?”, but rather, “How do we decentralize IT in a centralized manner?”
