One of the questions I always get when I work with a company is "How should our IT be organized?" Here are some thoughts on what I've observed over the years.
First, there is no one right answer, no ultimate truth. As with many things in life, form follows function, and how you structure your IT organization should be about what you want to get done at that time as much as about anything else. For example, needing to reduce costs and eliminate inefficiencies will demand a different structure than would a focus on service delivery to the marketplace or growth through acquisition and integration.
There are also some complicating factors that muddy the discussion. Chief among these are the organization and assets already on hand. Companies are and should be loathe to treat their workforces as interchangeable commodities and, truth be told, a highly experienced manager who can get the job done should influence organizational decisions much more than some academic approach. Similarly, while it may be attractive to take advantage of the virtual organizations of suppliers, having the sunk cost of data centers and computing gear and in-place organizations will diminish the business case.
Also, there is the need to manage multiple dimensions of technology, customers, and geography, no matter what business you are in. If something is important, there should be one person ultimately responsible for seeing that it gets taken care of, and this will inevitably create ownership conflicts. For example, there should be a manager of networks, but if the HQ is in NY and there is an office in LA, the LA office will require support staff, too. Should the comms folks in LA report to the regional business head or to the functional network head in NY?
Here are some basic guidelines you might find helpful in thinking through how you should be organized:
• Start with roles. Have one clearly defined person responsible for every important job, before you let your mind wander to how the roles are organized.
• If the intent is to reduce cost and foster asset leverage, then centralize management.
• If the intent is to increase service at the customer face, then decentralize, maybe to the point of having the local function report to the business.
• Transformational times require central, singular leadership.
Infrastructure and operations are examples of areas that should be organized centrally. They respond to asset aggregation and are essentially commodity services; the company will benefit more from everyone having the same email system than it will from everyone making their own decisions. The pressure to reduce costs in these areas will never stop. The local businesses may scream that they need to control their desktop support techs, but you should tell them that managing these folks is not what they are getting paid for.
Applications Development is a service business and should report as closely to the customer it serves as possible. I say this with one caveat, though: Infrastructure systems such as GL and ER should report centrally, as should overall data architecture for the company. These actions will create the frameworks and governance that the local teams can work within.
This is all fine for business as usual, but when you are undergoing a turnaround or are in the middle of an M&A moment, you need it all to be centrally led. Action was never taken by a committee.
I hope you are getting from this post that I believe that Organization is actually not that important. It is Governance that counts, i.e., how decisions are made, the transparency with which the process occurs, and who is empowered to make them. Toward this end, I will leave you with the following suggestions for things you should undertake regardless of your organization.
• Create governance. This is the true role of the CIO.
• Regardless of who reports where, aggregate all spends and report centrally.
• Look critically at Infrastructure relative to the market. The long-term trends are in favor of external sourcing, and you should be prepared to make the transition as it comes.
• Think strategically about Application Development. Faster time-to-market of new apps is a competitive advantage. If you look at an app and see that it is not going to change, then it is Infrastructure and should be governed by the same rules. ###