‘Shadow’ IT and IT Support – Let’s Get Real

‘Shadow’ IT is the industry’s unenlightening and somewhat patronising, yet de facto term for other IT service providers within the business (Wikipedia definition here). These alternative providers may be looking after vertical, department-specific or sometimes general local IT, and may or may not be officially sanctioned at corporate level. What they have in common is that are not technically under the central corporate IT budget and control.

First let’s get this misleading and frankly unhelpful term out of the way. ‘Shadow IT’ is not shadowing anything. It’s not casting a shadow over central IT and it certainly is not “following or observing something closely or secretly” (Google definitions). If conventional IT can be seen as the ‘corporate’ version, how about if we call ‘Shadow IT’ something a little less dramatic and a lot more descriptive, like ‘User-Owned IT’.

User Owned IT takes many forms, but the function of it that I’m looking at here is, for want of a far better term, ‘User-Owned IT Support’. That is where the users have somewhere else to go for technical support for their IT installations, even before or instead of calling the official helpdesk or service desk.

User-Owned IT Support is not necessarily a good thing or a bad thing per se. It’s just a thing, and the question of whether it’s good or bad for your organisation depends on how it suits your business and how the status quo was arrived at. Here are three examples of how I’ve seen Shadow IT Support behave and evolve on client sites and how it affected IT support delivery. I’ll end with some conclusions and an approach to the phenomenon.

The ‘Practicality’ example

A certain high technology company occupies a twenty-odd acre site in the Home Counties of England. The site does it all – in numerous buildings are factories, laboratories, distribution and warehousing, and an extensive Executive Block. The effect of all this diversity and separation caused the various buildings to establish, more or less organically and in response to local demand, their own desktop IT support. Several of the buildings already had local support for vertical applications and systems only relevant to their own function, and that’s understandable; but they hired their own first- and second-line, office-user support technicians as well.

It was only a matter of time before somebody (you guessed it, a new manager making his mark) would point out the inefficiency of all this apparent duplication and decide that centralisation would be better. One central service desk, requiring fewer staff, and being on a contiguous, albeit large campus, backed up by centralised but peripatetic desktop support staff.

The resulting user support was numerically one of the most efficient I’d ever seen, with staff motivation and productivity in the upper percentiles all the way. Yet six months after an expensive and painful centralisation, little IT departments began to emerge in various buildings across the campus. Most of the time, they were the local chap who knew more about computers than his colleagues. In the case of the Executive Block, this happened to land, rather expensively, on the desk of the Assistant Director of Marketing. Hundred grand a year, tailored suit, under colleagues’ desks fiddling with dusty cables.

The centralisation money had been wasted. User-owned IT support had re-emerged because it was perceived to be needed. The four-hour wait for a solution from one of the consistently fastest IT support groups I’ve ever seen, simply wasn’t good enough. And with that, the credibility of central IT management took another blow for trying to convince the users it would be.

The ‘For Accounting Reasons’ example

There was a similar case in another organisation, with buildings much further apart, all representing seven sizeable companies which had been acquired. Here, it was political too – “you new chaps now report to head office”. In the reorganisation, IT support second line was left at the premises, but first line was centralised into a common “Service Desk” and, to reduce financial liabilities, outsourced.

First liners who had known their local site realities were relocated from their seven sites into one. Some couldn’t move, for family or other reasons, and so were allowed to leave the company and replaced with contractors. Now, if any given user called the Service Desk, there would be a less than one-in-seven chance that they would be speaking to a technician who even knew that part of the business existed, let alone could resolve the enquiry – and in the case of the outsourced staff, that technician was also working for another company with a different profit motive than the user. These innate interest conflicts added to service impediments. Communications increased in difficulty, the first time fix rate plummeted, second line became much busier, so fix times lengthened and the service level nosedived. Training was tried, but it couldn’t replace experience.

Within three months, high powered user delegations demanded a solution. So the newly centralised Service Desk was split into seven Service Desks.

Be careful about asking an accountant to make service level decisions. There is much you will be missing and it may well come back to bite you. User-owned IT Support, in the form of local, specialist services, can sometimes actually be a good thing.

The ‘Pragmatic Self-Reliance’ example

Then there was the medium-sized company with a central HQ, and various smallish, distant outposts for sales and local representation. Hundreds of users based at HQ, a few dozen at each of the other equally vital installations. In terms of calls-per-user-per-year, hardly any came from the remote sites, even though they used the same IT as the head office users who swamped the Service Desk every day.

The difference in support needs was not technological – it was behavioural. The remote users knew that same-day at-desk support wasn’t coming. The bigger satellites of 80-odd users did indeed hire their own techie, but the smaller ones of 10 or 20 users knew they had to rely on themselves. So they didn’t forget their passwords, they kept local backups, they consulted help files, they learned their IT, and they took full responsibility for their own use of it. A form of ‘Shadow IT’ may even be no IT at all – ain’t nobody here but us users.

Consequences

User-owned IT is a potential threat to IT quality because it means there is inevitably more than one standard of IT delivery in the business, and often no overall governance to impose uniformity. So quality of service and veracity of solutions cannot be universally guaranteed.

As an entity, the small remote site is another type of, possibly deeper threat – because their version of Shadow IT is done more at the user level. Users like these raise the bar of what actually constitutes an IT Support need, far higher than tends to be the case where there are large clusters of users. Those little remote sites are a threat only because they show us how little the users would really need us if they got more of a grip of their tech. They might be able to do without us altogether, weakening both our position and potentially, the overall quality of IT and Support at a corporate level. But they are a practical reality for us to deal with. Accomplished and self-reliant remote users are not over-awed by IT. They use it like IT people do, just like the tool it really is, as there to be understood and exploited.

But what do you do when you have many such small presences, perhaps continent-wide? I once worked with a company who had been using a global computer services provider to look after myriad such sites all over the world, outsourced technicians visiting the sites once a week. They eventually dropped that policy in favour of an acknowledgement that the users were going to support themselves anyway, so they imposed a locked-down desktop, and provided a local stock of spare laptops backed up by a next-day courier service for replacing faulty kit.

Conclusions

Perhaps we technocrats have to take the insult on the chin. Where User-owned IT Support emerges, it often does so because the service as offered by central IT is either perceived, or indeed is unable to meet the local business needs. We’re not good enough, so the users have to do it for themselves. ‘Good enough’ is perhaps too judgemental – ‘appropriate’ may be more accurate. Physical distance notwithstanding, the users want it local, and are prepared to pay for it, either in the salary of a local, purpose-hired and possibly under-utilised technician, or by sacrificing their own productivity to providing a surrogate IT service themselves.

Where ‘Shadow’ IT Support is happening, in my experience a central IT response of trying to force a change for political or accounting purposes alone is unlikely to be successful in the longer term. There may still be a real need for local support and if necessary, it will continue to be met, but now on the QT. It is understandable, however, to try centralisation and see the effects, because that will better inform future decisions. But always beware the risks of setting the users against IT.

If User-owned, ‘Shadow’ IT Support turns out to be vital, my usual advice would be to not attempt to take control of it, for it belongs to the users, not to IT management. Instead, consider offering to hook it into the central procedural framework, so that it shares in the use of central IT Support tools and techniques, and gets a formal escalation route via central, that the distant user can understand and accept. User-owned IT becomes part of a collective, homogenised workflow.

In other words, if ‘Shadow’ or User-owned IT Support is inevitable, let us not compete with it – let’s ally with it. That way, the users keep their independence and the right to mould their IT Service to how they want it to be. Over time, we’ll learn what that difference is and perhaps be able to tailor our own services to meet it. Meanwhile here in our new, collective IT Support, we central technocrats get to influence, and ideally ensure consistent Support service quality, regardless of how, where, or by whom the service is delivered.

Leave a Reply

Your email address will not be published. Required fields are marked *