What is Shadow IT?
There was a recent conversation online about the dangers of “Shadow IT.” In case you are unfamiliar with “Shadow IT,” it is simply IT-like projects that are initiated and developed outside of the IT department.
This can be a custom application, a “rogue” server, and even technology systems purchased outside of IT. The general consensus is that these projects and technologies present a risk to the organization and to IT. Truth is, they do…. or at least, they certainly can.
There is another question however; perhaps the most critical question: Is “Shadow IT” always a bad thing? Or can “Shadow IT” provide an insight into the needs of the business and also expose innovators and innovation?
My response – with edits – to the discussion of “Shadow IT” can be found below. I add a few other ideas after that.
Rather than fighting “Shadow IT,” IT professionals and departments had better understand why it exists and the amazing opportunity for innovation it provides.
The truth is, in my coaching and consulting, I look for those innovators and often provide them tools to help those projects fall more into line with IT standards. In fact, “Shadow IT” isn’t in the shadows. It’s a boots-on-the-ground, solve the most pressing problem, get $#@*! done endeavor in many cases.
When I was employed with a large insurance company (pre consulting, pre coaching, pre entrepreneurship), I was NOT in IT. I’m so thankful for that, because IT – rather than focusing on innovation and solutions – is often focused on governance, security, protectionism, and controlling the environment.
Process and Protocol is Important but…
Before I start to get the push back.. yep.. those are things are needed – but if that is your focus as an IT leader, your IT group is NOT a business solutions and end-user tools department, but a lowest-cost provider of non-innovative technology. That’s a bad place to position IT.
I’ll go further and suggest that the BEST ideas for what users need and their perspective of what IT provides is probably there in the shadows…. with the users…. using the technology. Imagine that!
At the above mentioned insurance company, IT was, centralized, controlled…. but I was building solutions for a large department and two up and coming executives. As things progressed, IT could NOT keep up with their requirements and the changes we were putting into place. My boss at the time gave IT a mandate…. either:
a) teach, train, and coach me to manage the IT resources we needed so that I could make the needed changes (not without some notification)
b) she and her boss would simply build their own IT infrastructure, servers, etc – and give me control of that.
They were making the company a bucketload of money and were strong enough to NOT be denied. Fortunately, the IT manager advocated for option a.
My “Shadow IT” project saved the company $1,000,000.00 in printing costs the first 14 months and a recognized increase in actual productivity of 600%. We had to retrain about half of the production staff and my boss ended up forming a new department because of that.
Of course, I should have received 10% of that savings as a bonus, but that didn’t happen. :-/
Shadow IT is an Opportunity
I have since been a CIO twice and serve as a Virtual-CIO for a couple of organizations. “Shadow IT” is NOT a problem…. it is an opportunity. Either an opportunity to recognize what you might be missing as far as real need or an opportunity to recognize where better end-user training is required because the projects, there in the shadows, are already solved somewhere else.
When I coach “departmental immersion” so that IT can see what really happens in departments and with users, part of the reason is to identify “Shadow IT” – although we call it seeking “opportunities for innovation.”
And maybe it is even an opportunity to identify where greater governance and control is needed. But beware the knee-jerk reaction that those “hacks” are simply risks to be mitigated.
That is short-sighted!
IT Should Have Seen It
Some suggest that “Shadow IT” is evidence that IT is not well-aligned with the business; that IT did not see the opportunity or need that was created by a user or in a department.
The error in this thinking is that innovation and “Shadow IT” projects are seldom fully-formed from the start. They are incremental, starting as a small piece of automation – an Excel macro, a small personal Access database, some desktop scripts, etc. They do not require a project. They don’t warrant IT’s attention.
Then, over months and perhaps years, the project grows, as does the skill of the individual(s) building it. They are not necessarily as tightly controlled as IT would like and certainly, as the project/solution grows, some oversight and direction from IT is warranted.
This is where magic should occur.
Rather than simply hijacking the project or shutting it down because it does not meet the standards of IT – in naming convention or in how it is rolled out, IT should first mentor and coach those building it.
They should also try to learn from it. If it is solving a pressing need and includes some great interface or innovative ideas, don’t play the “we are the technologists, you are just a hack” card.
IT bears responsibility for security and controlling the environment. But if IT wishes to be considered business savvy, innovative, and strategic, let the business and the users help you. They have a LOT of great information!
Rather than shut down “Shadow IT” – bring it into the light!