The IT department used to own the keys to the com­puting resources, literally and figuratively. The data center was the crown jewel of IT. To most users, it was impressive and mysterious, and a symbol of the relationship between IT and its users.

Because users in a line of business (LOB) had to go through the corporate IT department to obtain any IT resources, they had to follow the process defined by IT. This made the CIO or IT manager both powerful and resented. Few IT people understood the users’ plight of preparing justifications, listening to technical jar­gon they did not understand, and sitting in countless meetings until finally (i.e., after their project had been delayed by lack of the required capability) receiving a deliverable that may or may not have been what they needed. And then they got the bill.

What we have learned is that the cloud has enabled a shadow IT to emerge. That sounds scary (mostly to the IT people), right? But we have also learned that shadow IT is not totally a bad thing, as long as there is communication, coordination, architecture, and governance. Let’s discuss this more specifically.

Shadow IT means that each LOB, or each function (e.g., HR, marketing, sales, field service) is making its own decisions and paying its own costs for certain IT capabilities that it deems necessary, without going through the centrally controlled process on which we just heaped sarcasm. As a result, the agility benefit of cloud solutions can now directly and immediately benefit end users. Since many of these departments do not have the skills needed to perform a good study of their requirements and carefully select a solution, the decision process has shortcomings and can border on the arbitrary. Here are three typical ways in which a shadow IT solution is selected:

1. A department employee who seems to be pretty good with technology (often a junior one) is told to research and propose a solution.

2. A manager who has used a certain solution at home — for his homeowners’ association, say, or heard about it from a buddy at the gym — decides that it must be good enough for his business need (that’s how so many confidential documents end up being stored in Google Docs).

3. A consultant is hired to do the study. A very cheap consultant is chosen because the cost of this study needs to fly below the financial controls radar. In terms of the suitability of the recommendation, you get what you pay for.

What is typically not done is to go to the CIO and say, “Look, we need a solution for X, and we need it quickly. We’re not willing to go through a protracted process, and we heard that you guys typically take way too long. But we do want to make sure that what we choose will not create a mess; we want to make certain we can exchange data with other systems — even though we may not yet know what those are; we realize that we may need some form of support at some point; and we want to remain reasonably good friends. Will you help us achieve those goals? Call it a ‘proof of concept’ if that sounds better. And guess what, you’re even going to learn something useful in the process, which could be applied elsewhere in the organization.”

Seen this way (i.e., very optimistically), shadow IT projects don’t quite deserve their name; they are no longer happening in complete darkness. They try to achieve a balance: work fast without having to jump through bureaucratic hoops, but not risk rejection by the host organism.

Some progressive CIOs understand the need to monitor, facilitate, and even embrace these processes rather than ignore or fight them. One way to do this (usually in a large enterprise because of the resource allocation that it requires) is to create a small “rapid reaction team” of IT specialists who work in quasi-startup mode. Their job is to quickly build prototypes for the internal clients, trying free or cheap solutions in the cloud, allowing decisions to be made in the course of days or weeks, not months, while keeping the IT organization informed and ensuring that the selected solutions can be integrated and supported. A key challenge is to protect this team from being “recaptured” inside mainstream projects when a resource crunch or an emergency happens.

If IT does not embrace agility in delivering solutions to the business, the business will go ahead and select solutions in the cloud without involving IT. But if the business procures such solutions on its own, integration will become very difficult.

[For more from the author on this topic, see “Cloud Lessons Learned.”]