[/caption]
As I get older, I’ve learned to listen to people rather than accuse them of things. — Po Bronson
While every IT organization has its own mission, they generally support technology operations, optimize the use of technology across the enterprise, and use technology to advance the business. In companies of any size the application portfolio supported is relatively large, there is duplication across business units, multiple platforms to support, competing architectures in play, and no end to the number of open issues and demands for new features in the application portfolio.
In order to meet this need, IT organizations are built around managing volume, oriented around large-scale initiatives, and work within defined processes and methodologies to prioritize among the enormous number of items competing for attention, and do so while minimizing the risk to all.
What this doesn’t allow is each department to have their important needs addressed immediately. This is where Shadow IT enters. Departments who simply cannot wait in line will handle their IT needs themselves. In doing so, the focus here is on speed to market. Typically any technology is fair game and often ends up rhyming withVisual Basic, Microsoft Access, or Excel. There will be few if any controls in place, and formal methodologies are a luxury. The “whatever it takes” drumbeat dominates Shadow IT.
A few key points here. The work done by Shadow IT will be able to get to market comparatively quickly. It may have a higher number of defects, not use any operational controls, and not integrate with other data / systems. But it will be quick.
Given this distinction, should departments use the IT organization or build their own Shadow IT group? An equally good question is should they have this option within a corporate governance structure? Both of these are questions are loaded with a great deal of emotion. Discussions take place at a high volume. Both sides have good points.
I believe that these decisions can be made without a gun being involved. There are clear trade-offs between the two approaches and it is not an either/or situation and there are many instances when quick application development outside of the IT department is a good solution and should be embraced by both the business and IT. For this to work, clear parameters need to be put in place. For example:
- everyone understands and is willing to accept the risks involved in working outside of IT,
- the business unit will fund the effort,
- the business will provide all on-going support for the effort,
- a select few application development platforms will be endorsed for use by Shadow IT, and
- a plan is put in place for the transition (at some point) into the IT department for long-term support.
With these items in place, harmony around this one contentious issue can be obtained.
Viva la difference.
Nice piece, Russ. When I was director of product for Interactive1 (SW company in London), your “shadow IT” was the target of our near-term market strategy. We had a suite of content tools that let us design and deploy large web-based services fairly quickly — but which we knew was not sufficiently competitive with the market leaders of the day to win acceptance by IT directors. So, we sought out projects run by business units of large corporations, where a quick deployment was required and the unit had independent signing authority of at least 100K. Usually, the IT exec wasn’t interested in fighting these unless they had enterprise-wide impact, or were high profile for some other reason. Sometimes you can also gain their support by promising migration to the enterprise standard tool set in a later phase.
– Greg
As a call center technologist, I generally find they need local IT resources to support the operation (versus depending upon centralized IT services). The rationale is simple: the real-time nature of the service model and customer interactions necessitates immediate turnaround to respond to dynamic conditions.
To avoid mayhem, companies need to adopt a state/federal model of IT governance that both permits local autonomy while driving standards adherence as much as possible. One can view this as another version of the thick client/thin client argument. I’ve always maintained that neither model is sufficient in practice, but both offer strong advantages. Why not have both? It seems this has been borne out over time, so perhaps the truths of technology can help us inform governance after all.
Thanks for the article, Russ. It’s a good topic!