In my previous post I described Shadow IT and the problems it causes. In this post I’ll describe some approaches that the formal IT organization can take to deal with Shadow IT, and I’ll give you some recommendations.
5 Approaches to Dealing with Shadow IT
Most formal IT organizations take one of five different approaches in dealing with Shadow IT:
- Ignore it. This can be dangerous for two reasons. First, since a business organization’s use of Shadow IT is an indication that the business organization is not happy with what your IT organization is providing, ignoring the Shadow IT means that you’re ignoring the fact that the customer organization is unhappy. And second, it’s quite likely that some of the systems purchased or written by the Shadow IT group will end up being “thrown over the wall” into the formal IT organization, or at least require interfaces with formal IT systems. So if you ignore Shadow IT now, then you (or your replacement) will regret it later.
- Fight it. This can work if the formal IT organization has enough support from the CEO. To fight Shadow IT successfully, you’ll have to create explicit standards on what can or can’t be purchased, built, or contracted for by the business organizations, and then you’ll have to police those standards rigorously. This works well if IT has a good relationship with the various parts of the business, so the approach’s success is highly dependent on the individual people holding the various positions. But you can’t let down your guard for a second — it’s very easy for a business executive to sneak something in when you’re not looking.
- Discourage it. This is a slightly milder version of “Fight it,” and it’s often easier than the “Fight it” approach when IT doesn’t have all the executive support you would like. You still need the explicit standards on what the business can or can’t do, but you have to pick your battles on what you fight and what you ignore.
- Work with it. This is a more proactive, positive version of alternatives #2 and #3. You define standards for what the business can or can’t do, and then you define further standards for how the business can do the things that they’re allowed to do. You can assign people to work with the Shadow IT groups to help them with technical decisions. And you can help them choose products and services which meet the business needs while conforming to the basic architectural standards you’ve established for the overall business. The approach is a tightrope walk, though: You’re walking a fine line between control and lack of control, and it takes some serious relationship management to make this approach succeed.
- Integrate it. This goes further than #4 in taking Shadow IT out of the shadows and making it an explicit part of your IT strategy. This is kind of like a decentralized approach to corporate IT where certain services and projects are done by the business IT organizations, and certain other services and projects are done by a corporate IT organization. Standards are decided jointly, and enforced by both the business and corporate IT organizations. This can be a very effective way to share technology direction setting across a diverse group of business organizations. But if it’s not done well, it can lead to more Shadow IT, or maybe we should now call it Shadow Shadow IT, since it’s in the darker shadows beyond the shadows.
How an IT Organization can Derive Benefit from Shadow IT
Used properly, Shadow IT can be a supplement to your formal IT budget. Think of it like overflow seating at an event: all of the normal seating is taken, and the overflow seating provides some measure of benefit at a lower level of service. So if you’ve got rigid constraints on your formal IT budget, but you need to accomplish technology objectives that require more money than your budget, Shadow IT can provide a way to achieve some of those objectives using other people’s money. This works best, of course, if you use alternative #4 or #5, and works least well if there is no communication whatsoever between the formal IT organization and the Shadow IT project teams.
It’s easy to get overwhelmed by just managing your formal IT organization, and obviously the coordination and communication with Shadow IT projects will make your life more complex. But if you can’t make a case for moving the budget to your own organization, or if your formal IT organization isn’t trusted enough for the business organizations to give their Shadow IT budgets to you, then you’ll have to do the best you can with the situation you’re given.
No matter which of the five approaches you choose, consider these recommendations:
- Don’t let the business disapprove a formal IT project and then let Shadow IT do it anyway. If there are business reasons why a project shouldn’t be done then those business reasons should apply no matter what organization does the project.
- Provide IT advisors to Shadow IT organizations to establish realistic expectations on data availability, and to help steer Shadow IT projects toward appropriate standards for software and hardware. The key word here is “help.” Be positive, not negative. You’re an advisor in this case — not a manager. Pick your battles wisely.
- Provide a “quick response” capability to do short-term projects without all of the red tape of the bigger projects. Carve out a specific percentage of your overall formal IT budget to be used for these quick response projects. Many of the Shadow IT projects come from frustration with having to live with systems issues that could be fixed fairly quickly, or with systems limitations that could be eliminated with a small amount of resource.
- Alternatively, let the Shadow IT people be the quick response providers as long as they conform to the standards set by the formal IT organization. This can be win/win: they get satisfaction using their own people, and you can focus your formal IT resource on doing the bigger projects.
Shadow IT can be your enemy or your friend; it’s all in how you deal with it. Start by getting it out of the shadows — if you don’t know about it, then you’ll never be able to cope with it, no matter which approach you take. Then choose your approach from the five approaches listed above, based on the trust level between the formal IT organization and the individual business organizations, and based on the support level that the formal IT organization is getting from the CEO. In many cases, you’ll find that you need a separate approach for each business organization because your relationship with each business organization is different. But whichever approach you take, keep up the communication between the formal IT organization and the Shadow IT project resources. You may be reporting through different executives, but you’re all trying to make things better for the same company.