Americas

  • United States

Asia

Oceania

Time to get out in front of shadow IT

Feature
Sep 28, 201511 mins
Network Security

Business colleagues with a technical itch can be effective allies if you foster a sane, productive strategy around DIY IT

It’s time to face a cold, hard fact: The “shadow IT” parade is passing you by, and if you don’t get out in front of it and lead it where you want it to go, you might get run over.

Gartner projected in 2012 that marketing department spending on IT will surpass IT department spending on IT in the near future. True, that has yet to happen, but the scales keep tipping. Take a hard look at that future: You may not be in it.

Shadow IT has been presented as a new threat to IT departments because of the cloud. Not true — the cloud has simply made it easier for non-IT personnel to acquire and create their own solutions without waiting for IT’s permission. Moreover, the cloud has made this means of technical problem-solving more visible, bringing shadow IT into the light. In fact, “shadow IT” is more of a legacy pejorative for what should better be labeled “DIY IT.” After all, shadow IT has always been about people solving their own problems with technology.

Here we take a look at how your organization can best go about leveraging the upside of DIY IT.

What sends non-IT problem-solvers into the shadows

The IT department is simply too busy, overworked, understaffed, underutilized, and sometimes even too disinterested to take on every marketing Web application idea or mobile app initiative for field work that comes its way. There are too many strategic initiatives, mission-critical systems, and standards committee meetings, so folks outside IT are often left with little recourse but to invent their own solutions using whatever technical means and expertise they have or can find.

How can this be a bad thing?

  1. They are sharing critical, private data with the wrong people somehow.
  2. Their data is fundamentally flawed, inaccurate, or out of date.
  3. Their data would be of use to many others, but they don’t know it exists.
  4. Their ability to solve their own problems is a threat to IT.

Because shadow IT practitioners are subject matter experts in their domain, the second drawback is unlikely. The third is an opportunity lost, but that’s not scary enough to sweat. The first and fourth are the most likely to instill fear — with good reason. If something goes wrong with a home-grown shadow IT solution, the IT department will likely be made responsible, even if you didn’t know it existed.

The wrong response to these fears is to try to eradicate shadow IT. Because if you really want to wipe out shadow IT, you would have to have access to all the network logs, corporate credit card reports, phone bills, ISP bills, and firewall logs, and it would take some effort to identify and block all unauthorized traffic in and out of the corporate network. You would have to rig the network to refuse to connect to unsanctioned devices, as well as block access to websites and cloud services like Gmail, Dropbox, Salesforce, Google apps, Trello, and so on. Simply knowing all you would have to block access to would be a job in itself.

Worse, if you clamp down on DIY solutions you become an obstacle, and attempts to solve departmental problems will submerge even further into the shadows — but it will never go away. The business needs underlying DIY IT are too important.

The reality is, if you shift your strategy to embrace DIY solutions the right way, people would be able to safely solve their own problems without too much IT involvement and IT would be able to accomplish more for the projects where its expertise and oversight is truly critical.

Embrace DIY IT

Seek out shadow IT projects and help them, but above all respect the fact that this problem-solving technique exists. The folks who launch a DIY project are not your enemies; they are your co-workers, trying to solve their own problems, hampered by limited resources and understanding. The IT department may not have many more resources to spread around, but you have an abundance of technical know-how. Sharing that does not deplete it.

You can find the trail of shadow IT by looking at network logs, scanning email traffic and attachments, and so forth. You must be willing to support these activities, even if you do not like them. Whether or not you like them, they exist, and they likely have good reasons for existing. It doesn’t matter if they were not done with your permission or to your specifications. Assume that they are necessary and help them do it right.

Take the lead — and lead

IT departments have the expertise to help others select the right technical solution for their needs. I’m not talking about RFPs, vendor/product evaluation meetings, software selection committees — those are typically time-wasting, ivory-tower circuses that satisfy no one. I’m talking about helping colleagues figure out what it is they truly want and teaching them how to evaluate and select a solution that works for them — and is compliant with a small set of minimal, relevant standards and policies.

That expertise could be of enormous benefit to the rest of the company, if only it was shared. An approachable IT department that places a priority on helping people solve their own problems — instead of expending enormous effort trying to prevent largely unlikely, possibly even imaginary problems — is what you should be striving for.

Think of it as being helpful without being intrusive. Sharing your expertise and taking the lead in helping non-IT departments help themselves not only shows consideration for your colleagues’ needs, but it also helps solve real problems for real people — while keeping the IT department informed about the technology choices made throughout the organization. Moreover, it sets up the IT department for success instead of surprises when the inevitable integration and data migration requests appear.

Plus, it’s a heck of a lot cheaper than reinventing the wheel unnecessarily.

Create policies everyone can live with

IT is responsible for critical policies concerning the use of devices, networks, access to information, and so on. It is imperative that IT have in place a sane set of policies to safeguard the company from loss, liability, leakage, incomplete/inaccurate data, and security threats both internal and external. But everyone else has to live with these policies, too. If they are too onerous or convoluted or byzantine, they will be ignored.

Therefore, create policies that respect everyone’s concerns and needs, not IT’s alone. Here’s the central question to ask yourself: Are you protecting the company or merely the status quo?

Security is a legitimate concern, of course, but most SaaS vendors understand security at least as well as you do, if not better. Being involved in the DIY procurement process (without being a bottleneck or a dictator) lets you ensure that minimal security criteria are met.

Data integrity is likewise a legitimate concern, but control of company data is largely an illusion. You can make data available or not, but you cannot control how it is used once accessed. Train and trust your people, and verify their activities. You should not and cannot make all decisions for them in advance.

Regulatory compliance, auditing, traceability, and so on are legitimate concerns, but they do not trump the rights of workers to solve their own problems. All major companies in similar fields are subject to the same regulations as your company. How you choose to comply with those regulations is up to you. The way you’ve always done it is not the only way, and it’s probably not even the best way. Here, investigating what the major players in your field do, especially if they are more modern, efficient, and “cloudy” than you, is a great start.

The simplest way to manage compliance is to isolate the affected software from the rest of the system, since compliance is more about auditing and accountability than proscriptive processes. The major movers and shakers in the Internet space are all over new technologies, techniques, employee empowerment, and streamlining initiatives. Join them, or eat their dust.

Champion DIY IT

Once you have a sensible set of policies in place, it’s high time to shine a light on shadow IT — a celebratory spotlight, that is.

By championing DIY IT projects, you send a clear message that co-workers have no need to hide how they go about solving their problems. Make your intentions friendly and clear up front: that you are intent on improving business operations, recognizing and rewarding innovators and risk-takers, finding and helping those who need assistance, and promoting good practices for DIY IT. A short memo/email announcing this from a trusted, well-regarded executive is highly recommended.

Here are a few other ideas in helping you embrace DIY IT:

  • Establish and publicize “office hours” for free consultations to help guide people toward better, technically informed choices. Offer advice, publish research, make recommendations, and help any way you can.
  • Offer platform services to make it easier for co-workers to get the cloud resources they need while providing known, safe environments for them to use.
  • Ask people what software or systems they’re using — a simple survey or email can reveal a lot. Offer a checklist of software you think people might or should be using with a few blanks for services not listed to get the conversations started. Encourage people to track what they really use for a day or a week. Let them know you are looking for existing solutions to enhance and support, not searching for “contraband.”
  • Examine your internal server/email traffic. Are there patterns or spikes of large documents or long-running connections? Investigate the source of these, and help them optimize. For example, if design engineers routinely email each other gigantic design documents every Wednesday, provide them with a secure shared drive to use instead. Follow the bandwidth to get to the source — and help them work better.
  • Examine your support load for patterns, such as an uptick in calls for new software or unsupported/unrecognized software, or a severe downturn in calls for old software. This may indicate that an older, problematic system has been surreptitiously replaced.
  • Publicize and praise prior DIY IT projects, recognize and reward their creators, and share their results and techniques with other departments. To spread successful practices, provide proof of your good intentions and publicize the benefits of reasonable IT efforts outside the IT department. Make it known, with strong executive support, that you want these projects to succeed and you want the fruits of these labors to be recognized, applauded, and shared for the betterment of the company.
  • Ask everyone, systematically, what they’ve done and/or need help with. Don’t ask, “Are you doing shady shadow IT things?” The answer will be no, of course not. Instead ask, “How can we help you eliminate or simplify repetitive, mind-numbing activities?”
  • If possible, provide a roving high-caliber but small team of IT and devops specialists to make “house calls” to help people get set up, fix problems, and improve DIY IT projects. This will help the projects succeed while remaining compliant with balanced IT policies. Plus, being visibly proactive and helpful is good for public relations.
  • When warranted, embed a small IT team within a business unit to help them solve their larger problems, and share that learning with the rest of the company.

DIY IT can be a great benefit to your organization by relieving the load on the IT department and enabling more people to tap technical tools to be more productive in their work — a win for everyone. But it can’t happen without sane and balanced policies, active support from IT, and a companywide awareness that this sort of innovation and initiative is valued.

Related articles

steven_lowe

Steven A. Lowe is a consultant, software developer, inventor, entrepreneur, author, musician, and lover of puns. He ran an innovative custom software development company for nearly a decade before joining ThoughtWorks as a Principal Consultant in 2014. He admits to being the author of "From Burnout to Bonfire" and a willing participant in the band Noise in the Basement, but neither confirms nor denies being the science-fiction author Steven Ayel. Disclosure: He also writes for Hewlett-Packards marketing website TechBeacons.