Emerging Tech investigate

Sanity check: Counterpoint -- five reasons to decentralize your IT department

Last week I gave you five reasons why you would want to centralize the resources of your IT department. Now here is the counterpoint: the top five arguments for decentralizing IT.

I extolled the benefits of centralizing your IT department last week, and now I'm going to provide the counterpoint: the top five advantages you can gain by decentralizing your IT department.

5. IT is a smaller target for budget cuts

Decentralizing primarily involves taking parts of the IT department - for example, software engineers for custom projects or help desk professionals - and assigning them directly to a department or business unit. This leaves a smaller group of professionals in the central services wing of the IT department. One of the advantages to this is that IT is not such a huge target when it comes time for budget cuts, and the IT workers in the business units are much more closely tied to revenue and so less likely to be viewed as expendable.

4. Less bureaucracy to manage

With a smaller group of IT professionals in central services, there are typically fewer groups, less hierarchy, and less political in-fighting. All of that adds up to less bureaucracy for IT leaders to manage, which means more time can be spent on developing effective IT strategies.

3. Projects get done faster

When you have developers, engineers, and architects tied directly to the business units, they tend to need fewer meetings and less communications in order to get on the same page with the stakeholders on the business side. That's because they work more closely with the business side on a daily basis and typically report up through the business leaders of the division. This type of streamlined communication can lead to projects that get done much faster and more efficiently.

2. Achieve better IT/business alignment

When business unit leaders have IT professionals and IT teams who are part of their department, they tend to demonize IT far less. And when IT pros are part of a business unit or department (in a large organization), they often do a much better job of learning the business and finding the technologies that can enhance it.

1. Increase responsiveness to users and customers

The number one value proposition is speed. Requests don't have to go into a central queue and then wait for the appropriate and/or available technologist to handle the request. Business leaders can work directly with the technologists in their business unit to solve problems, make changes to a project, tweak plans, make purchases, etc. This often results in much higher internal satisfaction with IT. For some businesses, this can also translate directly into higher customer satisfaction due to the perception of increased responsiveness.

For more on this subject, see:

Also, if you haven't already, please take our poll on whether you consider your current IT department to be centralized or decentralized.

Bottom line for IT leaders

Decentralization can result in an IT department that is leaner on central services, less of a target for budget cuts, gets projects done faster, is better aligned with the business, and provides better user satisfaction. However, keep in mind that decentralized IT also results in duplication of effort, places a much higher emphasis on multi-talented IT professionals, allows for less skill specialization, and is typically more expensive - although the costs are more spread out and absorbed into the operations of the various business units.

About

Jason Hiner is the Global Editor in Chief of TechRepublic and Global Long Form Editor of ZDNet. He is an award-winning journalist who writes about the people, products, and ideas that are revolutionizing the ways we live and work in the 21st century.

35 comments
ebeiyamba
ebeiyamba

This process will indeed improve productivity but will discourage skill specialization.

melekali
melekali

in your scenario. In our work environment, I think it would be more effective if we were all under one roof. The fortunate thing for me is I don't have as much supervisory responsibility, so I can spend more time managing the technical part of our work and far less time managing personnel.

YouCanBeReplaced
YouCanBeReplaced

You IT punks drive me crazy. Remember you work at a company to make it sucessful. The fact that some of you have a problem with aligning yourself with business needs just shows how worthless you have become. Turn off your Office Communicator and get to work. If not, you will be replaced soon...

bill.shen
bill.shen

They are not reasons for decentralize IT.

I'd rather be drumming...
I'd rather be drumming...

Perhaps at the functional area level in a decentralized IT org. The flip-side is that the Enterprise usually ends up getting clobbered, and redundant apps/db's run rampant. Everyone has their own definition for the same term, and their version of the truth fits in their world. With six copies of a database, it's hard to know which will be considered the most accurate for executive decision makers needs without a bit of extra analysis. I've even seen five different approaches to calculating something as simple as net landed cost. Decentralizing may provide a nimbler approach to delivering software, but I suggest that an enterprise level team should be responsible for the db and for cross-system integration.

dburr
dburr

Its not the method its the term "Decentralize" I hate it when concepts that have been around since the stone age get some new title and some how its new. Its just good planning and the stragtegic allocation of resources, its not really decentralized. Case in point: If you think of it in terms of the Miltary where you have divisions, batalions, strike forces, etc.; very decentralized under these definitions, but it all runs out of central commmand. The idea is not new, so rather than calling it "Decentralized", which it is not, how about calling it what it really is: The appropriate and strategic deployment of IT resources.

viswanadh.nudurupati
viswanadh.nudurupati

According to me the decision of IT to be centralized or decentralized is dependent on many factors. Few of them, the type of organization, type of products or services that an organization sells or offers, business processes and their dependence on IT. I prefer that organization should adopt a mixed structure for reaping the benefits of both the centralized and de centralized IT. The organization has to balance the extent of centralization and decentralization of IT in their Business process. At the strategic level, business processes such as development of IT strategy, IT Budgeting, Best practices development, IT resources plan etc., should be centralized and at the operational level, execution of projects, requirement capturing, resolving issues/complaints, implementation of Best practices etc., should be decentralized. This helps both the ends (Top and lower level management) meet together for achieving the goals of an organization such as Low Costs and High response times. The IT department has to find the processes which can be Centralized and which need to be Decentralized in view of the Business Goals and Objectives. IT has to align with the Business to meet the stakeholder's expectations. Note: The Views and opinions are those of the Author and do not necessarily represent the Views and opinions of Wipro technologies.

rellis1949
rellis1949

Several respondents have suggested that a combination of centralization and decentralization activities tends to be more effective for the IT Department of an organization. Developing a hybrid form of centralization can be more effective for a number of organizations, depending largely on the diversity of the organization in relation to the organization's overall mission and geographic structure. IT Departments must be assigned power as defined by the informational needs of the organization and, respectively, must have the ability to work as one of the holistic subsets of an organization. IT Departments should have a strong business orientation to ensure support is directed towards achieving organizational goals. At times, decentralization can ensure that supporting IT Departments have the capability to provide directed assistance to functional areas that, by virtue of the systems concept, would provide constant indirect support to help functional departments better achieve organizational goals. Total centralization can mean political biasing that can affect the appropriate distribution of IT support to functional departments that have weak relationships with the IT Department and/or management. Regretfully, those same functional departments may perform a relatively important set of missions that affect the organization as a whole. The resources withheld from critical areas could negatively impact the overall performance of the organization. Total decentralization can lead to inconsistencies in hardware and software resource acquisition and distribution. The effect of inappropriate resource allocation and distribution may assist a functional or geographic department in its growth. However, the decisions made through decentralization may rob other organizational areas of resources that would better support the major goals of the organization. Hybrid centralization would allow IT resources to be deployed more quickly to critical areas while allowing more general decisions for resource acquisition and deployment to be consistent. Respectively, consistency does allow the IT Department to be more efficient and effective in procuring and distributing generalized resources.

joemc
joemc

If you are ever going to go full bore completely in one direction, I would go with decentralized. I've worked in both environments (currently in a fully centralized organization), centralized can save you some money, but over time, the customer suffers in this environment. Decentralized is much more responsive and engaged with the customer, and experiencing both, I'd have to say decentralized is witout a doubt in my mind, better. You definitely get more done, in quicker time frames, and is much more focused on the customer. I agree with one of the comments that you need to utilize a combination of both, where appropriate. Infrastructe can be handled centralized - however, applications and support should be decentralized.

billr
billr

I am not sure I will agree with this senario for IT departments. The first issue is smaller groups means employee absence will cause a larger burden on the users and IT department in question. Second concern deals with workloads. In my experience, IT workloads are not consistant. With smaller pockets of IT offices, this can and normally will cause degration of support professional availability during these high workload times. I do agree however that this type of alignment will work for the very large (I am thinking over 5000 desktops) as a single IT department would be very large. Another positive, if a company can decentralize the IT department to have some professionals at each location, this will increase user satisfaction, less frustation which can be caused by Phone/Remote assistance. And having a IT professional onsite extends IT ability to troubleshooting hardware and network failures.

NickHurley
NickHurley

Most of this stuff seems to stem from poor communiation channels between various parts of the business and IT. A business should be like an organic body with IT like part of the immune system (we keep things safe and running). If information can't be conveyed effectively things will get naffed up, wires cross, tempers flare and so on. Seems like a placebo for middle management disease.

SeasonedsysDBA
SeasonedsysDBA

This debate is over 20 years old. Today's successful IT organizations are both. For example, take a centralized (via management using dynamic common standards, policies, and procedures) Database Aministration staff that is located across three countries and six sites, and deploys and supports a global database infrastructure located in two central and eight smaller sites - would that be Centralized or Decentralized? You see, there are no more hard boundries today keeping a centralized organization from acting decentralized. So tear down all those walls you are building (decentralize) and at the same time, get everybody on the same page (centralize)!

DualWolf
DualWolf

I disagree with your number 1 and 2 answers. We are putting in a front line help desk to avoid this because users were calling the programmers directly and we could not get any work done because we spent all day talking to users. We used to be very available to Accounting, which did have the benefits of being easily accessible and learning all of the business aspects. But, once the big issues were handled, we were constantly bothered with questions like "How come my printer isn't working?" and we were getting mired in petty computer problems. So, we put a wall up :)

tuomo
tuomo

Very good points but all that can be done in a well managed IT department also. IT departments just have tried to isolate themselves behind technology too long - it wasn't that way (a long time ago when IT was part of the business) but then it got too specialized and alienated itself from other business. I still would be against decentralization because IT is just a business function as accounting, sales, marketing, HR, whatever and breaking it would create a disrupt how well it can be done - seen that!

terry.bradford
terry.bradford

sadly we seem to be going the other way at the momment!

b4real
b4real

I think centralized IT is becoming quickly the trend. Consolidated costs are the main driver, but other positives are centralized resources and better staff utilization. The only gotcha is how to handle the footprint away from where IT is located. I battle with pieces of that daily. So I'd say I'd agree with last week's post more :)

Learning4ever
Learning4ever

Communication is the most vital tool of IT. If we can't commnicate with the decentralized IT work force lots of delays, poor customer service overall. If decentralized and lack of communication then IT completely dedicated to business unit better have all the controls and access to the various security, file folders,hardware-software know how and all programming and what not.... vast field for few individuals to know all the technology that is out there. Hmmm... So centralizing but behaving as decentralized unit is a good strategy as long as everyone is ready to serve the customer at first point of contact, Whole IT with all its different specialized fields should work hand in hand to achieve best customer satisfaction.

alpaca
alpaca

I've noticed a cycling between centralization and decentralization (and not just of IT). As organisations react to changing environments sometimes it makes sense to centralise and sometimes to decentralise...the trick is knowing which to do and when :-)

UK Dave
UK Dave

Unfortunately when you decentralise some IT departments you also get x number of different solutions to a problem and no standards as each department will come up with there own solution to a request from the business. An example i saw recently was a request originated in the business for a colour laser printer. This went to the site support people who ordered what they thought was the best printer for the requirement. It turned out to be from a manufacturer that we havnt used before and also completly imcompatible with our Citrix environment. This of course didnt go down well with the business, who pointed the finger at Citrix as the problem rather than the lack of company standards. Some IT areas do well being de-centralised, as long as they all work towards the same corporate standards.

Snak
Snak

I have been a solitary IT Support guy; part of a wider group spread across the campus, but in my own office in the department I supported. I have also been part of a small team of three, responsible for the IT Support of a School. I am now a member of a team of 13 providing IT Support to a faculty of schools. All of these have been for one employer who has, over recent years, centralised the IT Support system. Sounds on the one hand like promotion and on the other like demotion. Department to faculty, but own office to cramped, overpopulated collective. One thing that I have realised as I've become more and more centralised, is that the quality of service I can give to people is diminished. At one time I would know the user, know his/her machine and, when I was the sole guy, was able to have everything running smoothly. Now I find I visit far more people with only enough time to diagnose, fix and depart. Another thing I've discovered is that whilst the local IT Support person can be a hero, one of a 'team' is just part of 'that lot'. But the overriding reason why I think Centralised IT Support is Not A Good Thing, is that the Support Unit itself becomes more focussed on its own existance, than the reason they are there - and the user suffers for this.

dburr
dburr

I hate it when concepts that have been around since the stone age get some new title and some how its new. Its just good planning and the stragtegic allocation of resources, its not really decentralized. Case in point: If you think of it in terms of the Miltary where you have divisions, batalions, strike forces, etc.; very decentralized under these definitions, but it all runs out of central commmand. The idea is not new, so rather than calling it "Decentralized", which it is not, how about calling it what it really is: The appropriate and strategic deployment of IT resources.

Lost_in_NY
Lost_in_NY

is when organizations have a centralized reporting structure for IT (anyone who does IT work reports up the line to the CIO/CTO) and there are centralized standards, policies and tools (avoid redundancy, ensure hw/sw compatibility and provide company-wide visibility into what hw and sw we've got, and minimizing security risks), but where the staff placement follows a mixed model - centralized resources for company-wide considerations (supporting development for 'corporate center' type functions like Finance, HR and the like, central engineering group to manage the network and it's standards, central security and compliance group for those standards/policies and oversight), centralized 24x7 helpdesk to address all Tier 1 type of issues at any hour. But at the same time, locally embedded sysadmins/deskside support for those issues either beyond the Tier 1 folks (or where the users can't quite manage to follow the Tier 1 person's instructions...) and to provide valuable input into the centralized standards to make sure that any specialized needs of 'their' users are taken into account (e.g., IT person supporting R&D makes sure specialized software required by that department is vetted by the centralized security team and added to the safe list). Unfortunately, I've mostly been in organizations that were either totally centralized (which slowed delivery of IT services to the revenue-producing arms of the company, often due to thinking one size fits all...without taking any measurements), or too decentralized (local IT reported to/was evaluated by a business unit and had no incentive to comply with IT standards and policies which created a lot of waste and redundancy to the corporation as a whole...and tended to swing the cycle back too far to centralization).

oldemusicke
oldemusicke

The top 5 reasons to centralize or decentralize raise good points, but they also paint some false either/or situations. The two postings imply that your choice is to fully centralize or to fully decentralize. Few organizations probably do either to the total exclusion of the other. The real issue is deciding which elements of IT get centralized and which ones are decentralized. The various factors raised aren't entirely black and white either. Costs: Yeah, you can do economies of scale and whatnot by centralizing, but some costs could be more efficient by decentralizing, because you don't have to turn every solution into a corporate solution. Duplication of effort: Balancing what you centralize and what you decentralize can offset potential duplication of effort. Standards: You can still have standards at the corporate level, even if you decentralize many IT efforts. Business/IT alignment: Depends where you look. An IT group at the business unit can be better aligned with that BU's goals. A corporate IT group is probably better aligned with corporate goals. Responsiveness: Depends. An IT team at the BU level puts the BU's eggs in a smaller basket. If your small, local IT team is unavailable (busy, on leave, whatever), you're out of luck. A centralized IT group with good cross-over support can be more responsive and resilient. Politics: You get it either way. A tug of war over IT can still develop between a BU and corporate or between different BU's, no matter how centralized or decentralized your IT is.

Snak
Snak

IT Support should be based at the point of delivery. Centralised IT Support personnel tend to be badly maligned by users whereas on-the-spot support guys are all heroes. The biggest problem with centralised IT Support is the gap it opens up between the IT department and the users. Centralised IT Support tends to spend most of its time up it's own a***, looking after itself, rather than the users. As part of a general move towards centralised support, I've seen my credibility disappear as people comment 'Oh you're part of "that lot" now'. With a central IT Support Admin centre you do not need all the geeks under one roof. You need the geeks where they're er... needed - not in an office all together comparing Warcraft levelling guides. Far more support actually gets done with local support. And, let's face it, that's what IT Support is all about.

ceshull
ceshull

These are pretty good arguments for decentralizing an IT department, just as last week's were pretty convincing for centralization. But knowing the pain points of the people to whom we are arguing is the key. If the organization seeks to compete based on cost, it will typically be looking to trim anywhere it can. IT could actually get a budget increase if it convinces business unit executives (the holders of Profit & Loss (P&L) responsibility) that IT can streamline operations and save costs elsewhere. Or if IT is grossly inefficient, it may need to cut costs itself, and centralization may be just the ticket. However, it the organization seeks to compete by being more customer-oriented and/or innovative, decentralizing IT to the P&L groups should free them to make business case / cost-benefit analysis arguments to drive customer satisfaction or innovation. The organizational backdrop is vitally important! A well-managed and "plugged-in" IT organization may transcend these general rules. I spoke with several CIOs last week where were hot on the idea of "embedding" IT groups in the business units. Embedded or distributed IT groups live and work in the business units, but have formal reporting relationships to the IT organization as well. Having your annual review performed by both the business unit and the IT group generally helps embedded IT group leaders strike an effective balance between business-supporting innovation and responsible IT practice. -Chris

Susan_H
Susan_H

Decentralization may work if projects never cross business function lines. I am currently working on a project that requires coordinating development with order entry, warehouse receiving and shipping, transportation and finance as well as 3 outside entities--all with there own priorities. Fewer meeting? Less politics? Faster development? I think not!

ksady
ksady

Centralize - Decentralize that is the question. I work in a University that manages IT for thousands of students, employees and various other groups. Support is all over the place as far as desktops standards. OS choices. Java based applications with crossover requirements. All a result of a decentralized IT environment. It would be helpful if there was a group responsible for each segment instead of 70 groups responsible for 40000 users. Some controls need to be in place and that requires some degree of centralization.

michaelm
michaelm

I agree that at different points in a project/business lifecycle there will be different needs on IT Support, generally a de-centralized team to fast track a project or business unit in their time of need that can then reform part of the centralized team post implementation provides the best support and focus with the background of the centralized IT strategies,policies and procedures.

dcavanaugh
dcavanaugh

Indeed, it can be frustrating when the same problem gets solved in multiple incompatible ways. But sometimes the centralized IT agenda brings a great deal of inflexibility and overhead that business units are desperate to be rid of. The problem I have with centralized IT is that "What you have is all there is." If they are the sharpest people, then all is well and their brilliance carries great IT concepts throughout the entire organization. On the other hand, if they are anything less than that, we might get stuck with a self-perpetuating, unresponsive corporate fiefdom. What we really want is the benefit of both centralized and decentralized IT without the downside of either one. The risk is that the attempt might bring us the worst of both worlds. Surely there must be a middle ground in which decentralized IT is loosely coordinated. The economies of scale that brought us centralized IT have changed, which is why we need to revisit the centralized and decentralized components of IT. The goal of corporate IT should be to anticipate (and make allowances for) all of the things that decentralized IT might want to reasonably do, and take the edge off of the compatibility issues by keeping a flexible set of standards in place. Modern IT technology gives us the ability to be relatively vendor-agnostic and interoperable, IF we build our infrastructure with flexibility in mind. On the other hand, if the IT world consists of edicts such as, "We use proprietary vendor's technology X on platform Y and thou shalt conform, regardless of the cost, delay, or suitability for your specific needs", it's going to be a rough ride no matter who runs the show.

ScouterDude
ScouterDude

First it depends on which part of IT you're talking about. Desktop support has way different care and feeding than say development. We're largely centralized, coming from an historical mainframe environment, but some pieces are better placed 'out there', like desktop support. As for embedding that someone else mentioned, we go the other way - embed some critical functional users with the developers. That feeds into cost, as your developers can then be assigned multiple projects. The functionals work back with their depts for testing, etc. Responsiveness is mainly attitude. IT is a service provider, and you have to be customer focused. As others mentioned, IT doesn't exist for it's own purposes. Standards help costs long term. Higher skill levels in focused technologies, better integration. The biggest flaw I see here is people don't look for or pay attention to those with more experience that could provide guidance on new products. For example, sysadmins are likely better at reading thru the marketing hype, and wouldn't buy the crap apps sometimes selected by business units. And that can happen totally within IT, sadly. All in all, most any structure can work, given the right attitudes and leadership.

NickNielsen
NickNielsen

[i]Embedded or distributed IT groups live and work in the business units, but have formal reporting relationships to the IT organization as well. Having your annual review performed by both the business unit and the IT group generally helps embedded IT group leaders strike an effective balance between business-supporting innovation and responsible IT practice.[/i] This is a good idea, if implemented properly. The embedded IT can have only one manager, whether in the business unit or the IT group is immaterial. A manager from the other unit provides job-related input for performance evaluations, but has only that input to the evaluation itself. Anything else is a recipe for failure. Neither unit will be happy and the embedded IT will turn into a revolving door.

NotSoChiGuy
NotSoChiGuy

I was in an organization that had IT/IS groups closely aligned with business functions, and whenever a project or issue arose that crossed functional boundaries (Payroll, for instance, crosses HR and Finance), there was lots of politics, red tape and meetings (the meetings to plan future meetings were by far the worst). Based on my experiences there, I would say that intra-functional projects did get completed much faster than in a centralized environment. However, the inter-functional delays seemed to counter-balance any gains, and the net result was an overall average go-live/resolution timeframe that was fairly close to the sames ones I've seen in a centralized environment. The customer base in the decentralized environment did seem to have a better relationship with 'their' IS/IT teams than in a centralized environment of similar scale (25K-40K employees)...and the client surveys skewed higher as a result...so there was some good to come out of the decentralized environment. As others have posted, whether to go centralized or decentralized really is going to depend on what the strategic and operational visions are for IS/IT, and what the culture & environment of the organization are like.

blarman
blarman

The classic answer to the problem is "It all depends." Centralized IT is great (and usually a necessity) for security-oriented items such as anti-virus solutions, VPN's, websites, etc. De-centralized IT is usually better when specific organizational groups within a company have substantially differing needs that dictate individual solutions. So let me offer some suggestions as to what probably SHOULD be centralized, and what probably should not. Again, this is not an ultimatum, only a best-practices approach. Centralized: Anti-virus, firewall/Internet access rules, domain administration, website control, general help-desk, policy guidelines De-centralized: Application development, application help-desk, solutions teams

MrRich
MrRich

I've done this in the past. It works reasonably well, but when you place a team in the business unit (or functional area) you have to be constantly aware of the need to communicate with the team and keep them involved in whats going on in IT. They can tend to drift otherwise. Also you really want a main person you can trust, and you need to be sure that everyone knows who the team reports to!