“Give a man a fish and he eats for a day. Teach him to fish and he’ll wreck everything.”
– Bob Lewis, in Keep the Joint Running, regarding the philosophy many IT departments have about shadow IT.
“Give a man a fish and he eats for a day. Teach him to fish and he’ll wreck everything.”
– Bob Lewis, in Keep the Joint Running, regarding the philosophy many IT departments have about shadow IT.
Sometimes, the world changes quickly.
Six or so months ago, in a conversation with some fellow travelers in IT organizational effectiveness consulting circles, someone (ahem) raised the question of shadow IT and how best to support it. “I can’t imagine any circumstances in which we should even consider allowing it,” someone said, receiving near-unanimous support from the assembled multitude, yours truly being the reason it was only “near-.”
Last week I attended MIT’s CIO Executive Forum. In a table discussion at lunch, and also among many of the panel discussions, it was unanimous: Support for shadow IT is an increasingly important IT responsibility.
Which, as I’ve been advocating for shadow IT in some form or another since 1996, is gratifying. For you, it means advocating this no longer makes you a heretic.
If you’re a skeptic, consider the Transportation Security Administration (TSA).
Not its use, disuse, abuse, or quashing of shadow IT, about which I know nothing. What I do have is extensive experience waiting in TSA queues, and how it relates to process cycle time improvement.
Cycle time is the time needed for one item to move through a process from start to finish. When you’re waiting in the TSA line at the airport, total cycle time is measured in psychological months and chronological minutes.
Cycle time has two components: intrinsic cycle time and queue time. In TSA terms, queue time is how long you have to wait until you have to undress, empty your computer bag, and put your toothpaste and other non-solid toiletries on display.
Intrinsic cycle time is what elapses from the moment your first piece of luggage hits the conveyor until you get everything back on the other side of the machines subjecting you and your belongings to various indignities.
With TSA, intrinsic cycle time is actually quite short — no more than two minutes. Almost all of the wait we’ve all grown to detest has nothing at all to do with how long it takes TSA to determine who among us is or might be a threat. It’s queue time that tries our patience.
And interestingly enough, intrinsic cycle time isn’t the only factor driving queue time.
Capacity drives it too. If there’s just one inspection line open and the queue gets too long, TSA can and does fix the problem without any process improvement. It simply opens up a second inspection line and queue time is instantly cut in half, even though it hasn’t even nudged the dial on intrinsic cycle time.
What does this have to do with shadow IT and why you want it? Everything. Because the most important business benefit to be had by embracing, encouraging, and extending shadow IT is its impact on queue time, where its impact is little different from TSA opening the second inspection line.
Only in the case of shadow IT, the business is multiplying its application implementation capacity by maybe 1,000 percent, so long as IT doesn’t do its best to slow it down to industrial-strength IT speeds.
See, shadow IT has two natural advantages over industrial-strength IT. The first is that the trusted cadre known as we is responsible for all of the design decisions, where with industrial-strength IT, we in IT fall into the nasty group of untrustworthy ne’er-do-wells known as them. This is particularly true of the various trade-offs that are unavoidable in any design, but no more desirable because of their unavoidability.
The second advantage is that with shadow IT, most of the analysis and design work takes place inside a single person’s head.
Here’s why this is relevant. A lot of the reason we need methodologies when developing business software is because we have to coordinate the work of multiple specialists, each of whom understands a part of the problem; none of whom has the complete picture. Shadow IT doesn’t usually suffer from the need for all of this overhead. It’s pretty much one person’s show, front to back.
Meanwhile the single biggest argument against allowing shadow IT projects has pretty much fallen apart. That’s the contention that shadow IT frequently ignores the principles and practices required to implement properly secured systems.
This argument fell apart when Target, and Home Depot, and Humana all experienced major data breaches, all of which penetrated their properly secured systems … systems designed, built, tested, and implemented by IT professionals.
Conclusion: We’re over the hump with respect to IT recognizing the need to support shadow IT.
All that’s missing is a clear picture of what that support should look like.