IT Centralization or Decentralization?
People who read this also read:
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?”
For more on decision rights see:
Sign up for the Harvard Business Publishing Weekly Hotlist, a new weekly email roundup featuring the top highlights from HarvardBusiness.org.
- Comments (1)
- Join the Discussion
- Email/Share
Comments
Too many business issues are approached with structural change. The reason is simple. Structure change is relatively easy to implement and the change is obvious to the organization. Therefore, if the needle moves in a positive direction, the implementors can claim success.
In my experience, structure change rarely fixes IT issues. Until we find a solution to the perception of IT as a separate, self sufficient department in an organization (the way we think of sales, or accounting, or operations), I think we are destined to deal on a superficial level.
Try this thought on for a moment. I regularly encounter organizations where key business departments do one or both of the following: 1) come to IT with a specific problem and some sense of what needs to be done to solve the problem, but be unwilling or unable to define the business issues and prospective solutions in detail. They want to have a meeting and then hand the ball to IT to find a solution. 2) read an article or participate in a product demo, have an epiphany about how the solution could improve the business, and come to IT with an elegant solution to a vague problem.
Now, if I sound critical, I'm not. Both of these are valuable steps toward innovation, but neither go far enough. And here is where the perception I mentioned above comes in. If you view IT as you do the Sales department, the approaches above should be sufficient. After all, we expect Sales to come up with solutions when sales fall short of objectives. We expect Accounting to interpret the FASB rules and apply them to our business without a lot of input from other areas of the business. These dept heads are paid the big bucks to solve the problems in their area of expertise. I'm not sure IT can be approached this way.
Now, if I had the solution, I guess I'd be rich. But, I propose that we have to define IT differently from other departments in an organization before we solve many of the issues discussed in this blog.
Thanks for reading this note. I welcome comment.
- Posted by Bill Mitchell
July 31, 2008 9:28 PM