I recently informed the CFO (of the business division I support) that a corporate decision had been made to centralize Engineering and Product services.
His response: "Oh, I didn't realize the company hired a new CIO."
The business understands that when a new CIO joins a company, IT either moves from a decentralized structure to a centralized structure or vice versa. That's because any new CIO intends to make a mark, and the easiest way to do that is to take everything that's working just fine and blow it the fuck up.
Personally, I'm adamantly against the centralized model. On paper it looks good, especially to the corporate CFO because there's a huge cost savings associated with the model. But look under the hood and you'll find yourself staring at a bona fide lemon. Instead of making lemonade, the company asks you to drink the corporate Kool-aide and forget about logic.
Here's why I think centralized IT services is not in the best interest of the business:
Bureaucracy - Prior to decentralization, as a business engagement lead, I had control of the business analysts, the engineers, designers and product resources. After decentralization, Engineering became its own group and Product became its own group. With every new organizational structure comes new processes, and that means, more red tape to navigate and longer elapsed time for people to respond. Previously, the business came to me with a request and I told my staff to get it done. Post centralization, I have to go to two different groups to make a request that then goes into a queue until someone prioritizes it and gets the new (and unproven) process going. Does the request go to Engineering or Product first? The reason I don't know is because they don't know. It's been six months and they are still trying to figure out their processes. All this while the business waits impatiently. And by the way, the business can't go directly to Engineering or Product, they have to go through me. So I become a swivel chair. Also, Engineering and Product are insulated from Business noise, so all business complaints still come to me--but now, I no longer have the authority to take action to resolve.
Ownership and the Power Struggle - I'm one who accepts and craves ownership and accountability. If it's my project, the buck stops with me. I'm okay with that because I'm in control of how we execute and ultimately how successful we are. However, in a centralized model, I no longer have that control. Interestingly though--Engineering and Product still want me to have overall accountability. And yet, they want to make all the decisions. It's an unwritten rule in IT that we don't talk shit about other IT departments otherwise we convey to the business we're not unified and don't know what IT as a whole is doing. In other words, we all look stupid. So Engagement has to just smile and take it.
How do large projects work with this power dynamic? Like a slow boat to China. And when things go right, everyone will scramble to take credit; when things go wrong, believe me, everyone will point fingers.
Domain Knowledge - The strategy around centralization is to leverage the same resources across applications and reduce resource redundancies; this way, you can cut resources and have the few do what the many used to do. But in doing so, expertise suffers as the knowledge the support resources have for each application moves from specific and explicit to general and murky. Which is probably why Engineering and Product immediately jumped to flawed conclusions related to rationalization strategies: These three systems should be on the same platform. This conclusion was made after only a cursory review of the three apps--so even though the business purpose for each seemed related on the surface, the three systems were very different and NOT a good fit for the same platform. For example, just because a system has a financial aspect to it, doesn't mean the app is a financial system that belongs in SAP.
The good news for any organization planning to move from a decentralized structure to a centralized structure is that it will surely move back to the decentralized model after the business becomes so frustrated its top leader complains vehemently to the CEO and threatens to hire their own shadow IT group. The bad news is, it's about a 5 year cycle before it all unravels. The complaints will be about IT delays and overmanaged projects. And the business threat to hire its own IT team is real--I've seen it happen. That's when the real chaos begins.
I certainly understand the desire to cut costs through centralization; but what really matters is business enablement because that's how the company makes money.