Leadership optimize

The great shared service question

While operating with a profit-or-loss mentality can offer leadership opportunities and a drive for efficiency, there are several problems with a full-shared service model.

Several years ago, CIOs were admonished to build IT into a shared service, essentially creating a "business within the business" that would "sell" IT services to other business units and attempt to do so at the lowest possible cost. This strategy had some appeal. Presumably if IT was operating as a stand-alone business, it would be encouraged to streamline and operate in a cost-effective manner and would be available to anyone and everyone with a signed check. While operating with a profit-or-loss mentality can offer leadership opportunities and a drive for efficiency, there are several problems with a full-shared service model.

The ultimate commodity-shared service model is outsourcing

The most obvious problem with a shared service model is that it strives toward commoditization. If your "business within the business" had to maintain every potential competency, from maintaining desktops and network infrastructure, to having a raft of skilled implementation experts, there is no way it could be cost competitive. In this environment, your shared service tends to deliver primarily common commodity services. While there's nothing fundamentally wrong with this scenario, in even the largest organizations there is almost always an outside provider that can offer those same commodity services at a fraction of the cost, unless your company is in the IT services business.

While there's nothing wrong with outsourcing per se, from a perception perspective, the ultimate IT shared service is cheap and "out of sight, out of mind" until called into action. If you're a CIO striving to get a seat at the executive table and present IT as an entity capable of delivering on the organization's strategic and tactical imperatives, cheap and "out of sight, out of mind" are certainly not the fastest routes there.

Low cost usually equals lowest common denominator

Once you've built your shared service center and slowly optimized for commodity services, you're likely to be forced to exit the "solving complex problems" business. It's too expensive to keep high-end project managers and internal consultants on staff, and these needs will be fulfilled by outside vendors. There's obviously a balance since no IT organization can or should staff every conceivable skill internally, but a shared service mentality drives you too far in the opposite direction. In effect, the better you become at delivering a low-cost commodity, the more irrelevant an internal IT organization appears.

End the gymnastics

Perhaps the most wasteful aspect of an IT shared service is also one of its core concepts: chargebacks. Since a shared service is supposed to operate like a business within a business, other business units must generally "pay" internal IT for the services they consume. While conceptually straightforward, these exercises usually result in weeks (and in extreme cases, months) of accounting gymnastics, which at the end of the day do nothing more than move the company's money from the left pocket to the right. Most of these calculations do little to reflect market realities and occasionally have the unintended consequence of making internal IT appear grossly overpriced compared to the market, furthering the case against maintaining internal IT. In the worst cases, I've seen companies divide an employee's "billable hours" over the total cost of that employee (salary, benefits, paid time off, etc.), resulting in thousand-dollar internal bill rates for skills an average external vendor was charging $30 for.

Furthermore, it's tempting for an internal shared service to abuse what amounts to a monopoly position, again strengthening the case that there's no need whatsoever for internal IT. Put yourself in a business unit president's shoes and the case is pretty obvious. Pay exorbitant rates and sit through weeks of meetings with finance to engage in some accounting gimmickry or cut a check to an external vendor at a highly competitive price and be done with it.

There's a valid case for chargebacks in areas like a project environment, where providing a "blank check," sponsored by IT, could result in unending scope additions, but these scenarios should be the exception rather than the rule.

While a full-scale shared service model for IT is not a good idea, there are some elements to the model that can be beneficial. There will always be a commodity element to corporate IT, and this element should be delivered quietly, efficiently, and cost effectively. There's no shame in letting your network ops or desktop unit act as a "business within IT," striving to do things better, cheaper, and with less management oversight. Similarly, providing IT consumers with some idea of the cost of the services they are using is beneficial. I prefer a general menu-style approach, where everyone can gain an approximate understanding of what a particular service costs the company and which business units are the primary consumers of that service. Going off the deep end (I would put products that claim to calculate trivia like your "cost per single email" in this category) is not required.

The element of IT that should never strive for the shared service model is that which most demonstrates IT's value: the strategic and tactical component. While the majority of IT's time may be spent maintaining the boxes and wires, it's most visible activities should be around implementing the company's strategy through focused IT projects.

About

Patrick Gray works for a global Fortune 500 consulting and IT services company, and is the author of Breakthrough IT: Supercharging Organizational Value through Technology, as well as the companion e-book The Breakthrough CIO's Companion. Patrick has...

6 comments
blarman
blarman

The thing that always seems to get lost in all the outsourcing hullaballoo is that when you go looking outside your business for IT help, you lose one of the major bonuses of keeping IT internal: knowledge of the business. I have worked as both a consultant and as direct staff, and it takes dedicated time to grow to learn the ins and outs of how a business wants to do business. What many decision-makers fail to take into account, however, is how closely these business ins and outs translate to procedure, policy, and process in designing and implementing systems and keeping them running. This is information that any successful outsourcer is going to have to learn, and is IMO the main reason why companies that think to save money by outsourcing tend to spend a lot of money "managing" the project. What they are actually doing is teaching the outsource provider how your company operates so they can build your software! What a tremendous waste of time and resources! The other item that this mentality uncovers is the fallacy of the idea that all sources are the same for IT. The author hints at this when mentioning the "lowest common denominator" problem that is an inevitable outcome of focusing solely on cost without considering _value_. If managers fail to take into account - and this can be a very difficult thing to do - the value of the services provided when looking at just the costs, it is easy to decide that you are paying too much for IT. This mentality has a snowball effect, however, as managers begin to view IT as merely a cost, rather than as a value proposition. What compounds the problem is that this is a difficult cycle to break. Business managers need to look at IT as a value proposition not as a cost center. Those who can adopt this method of thinking will be able to more accurately evaluate their internal IT operations and realize the true value - or lack of it - within their organization.

Dknopp
Dknopp

Core IT work gets shuffled into the background and gets lost in this scenario. Capacity planning, root cause troubleshooting, etc. Since these services are normally not actually "billable" because they are considered BAU ( business as usual) and not directly part of an on-going project - which is billable, then the timesheets of the normally higher level technician, due to the complexities involved in this work - gets skewed to low percentages of billable time and looks like a liability instead of being the go-to person that they really are. These activities are directly linked to the business units ability to make money - no internet webpage due to a server running out of memory over the weekend - something that can be caught by good cap planning, and you can lose millions of dollars.

Diahnne Berthold
Diahnne Berthold

Hi Patrick, I think your description of Shared Services is perhaps not up to date? Shared Services is way more than a Shared Services Centre (SSC) that you describe. And I haven't heard of the "full Shared Services" model that you describe. As you state, a Shared Services Centre (SSC) is based on standardised, commoditised services. And I would add that in an effective SSC, a client can expect and get a consistent level of quality and timeliness for *standard* services such as a userid setup or a new PC. Surely most IT professionals would agree that's achieveable and reasonable? Your article seems to imply that every IT service is commoditised in Shared Services? I would say that's (i) not the intention of Shared Services (ii) simply not achieveable. Complex services such as Project Management or Enterprise Architecture are not commodities. These however can certainly benefit from Centres of Excellence, where scalable methodologies applicable to projects of various sizes and complexity are utilised, and applicable to all areas of the business. This is what I would call mature Shared Services. Also, chargebacks are optional. This is not a core concept of Shared Services. Neither is the "monopoly" described. If chargebacks are mandated without discussion and agreement or a monopoly setup without giving the internal client choice, then I would *not* call this shared services! Cheers, Diahnne

HuberCarl
HuberCarl

Awesome.....I got a $ 829.99 i-P??d2 for only $ 103.37 and my mom got a $ 1498.99 H-D T.V for only $ 251.92, they are both coming with U.S.P.S tomorrow. I would be an id!ot to ever pay full ret??il pr??c??s at plac??s like W??lm??rt or B??stbuy. I sold a 37" H-D T.V to my boss for $ 600 that I only paid $ 78.24 for. I use...,Tagcent.com

Diahnne Berthold
Diahnne Berthold

If a professional service is being provided, then as you rightly say these type of activities need to be undertaken for every IT service offered. My take is as it's part of the costs it then should be part of the charges. A mature approach to project management will include a Total Cost of Ownership (TCO) analysis as part of the original business case. So will include time/effort/resources required to do initial capacity planning as part of the project (even if it's performed by a team outside of the project). And then also ongoing capacity management, root cause analysis etc as part of the support for the IT service post go-live. Also in the business case, you include examples like the great one you've given - business units potentially losing millions of dollars because of an issue that could have been predicted and prevented. As you say, if there's a direct link between business units ability to make money and the IT services they receive, then the business case will stack up. If in your organisation cap planning, RC analysis etc are done as part of BAU, then I'd suggest perhaps adding a percentage or ratio of the BAU costs to every new project? After all, if you have new / upgraded IT services coming online then you'll probably need to hire more BAU staff and buy additional tool licences to support it!

MikeGall
MikeGall

corporate pays for "helpdesk"/BAU service for everyone. Then departments have their own budget for their IT needs. Anything outside of that has to be found somewhere else in their budget. I agree about the BAU though. I think it is silly that if you want to justify yourself you have to keep churning projects, somehow managing millions of dollars of equipment day to day isn't billable which is silly.