I’ve posted before about Shadow IT, but I want to revisit the subject – I think it’s a big issue that needs some more air. I’ve been reminded of this lately as I work with a client with a neglected IT capability. A new CIO has been brought in (the first sign that a hitherto neglected IT capability is now getting some attention) and he’s asked us to help him review the global IT operating model.
Among the challenges this CIO faces are a number of Shadow IT groups – small groups of people doing IT work around the company, but outside of the IT budget, governance, accountability or responsibilities of the “official, sanctioned” IT organization. BTW, when I come across Shadow IT groups that are known/recognized, I always wonder about other Shadow IT groups that might be lurking so deep in the shadows that they are all but invisible.
Shadow IT groups are often a symptom of unmet (or poorly met) demand. As such, they are prevalent in low business-IT maturity environments (i.e., demand appetite exceeds supply capability, so demand creates its own supply). Paradoxically, they are also prevalent in very high business-IT maturity environments, although we would probably never refer to them as “Shadow IT.” More likely we’d think of them as “power users,” or “embedded IT capability” and we’d encourage and celebrate such indicators of high maturity. So, rule 1 – it’s important to know why you have Shadow IT. If it’s a result of low maturity, I strongly believe Shadow IT needs to be integrated into the formal, sanctioned, budgeted IT operating model. If, on the other hand, Shadow IT is a result of high maturity, then the right infrastructure for them needs to be provided, and they should be prodded and encouraged.
Why do I think Shadow IT in low maturity environments should be eliminated? First and foremost, because they are a symptom of low maturity. If you are going to eliminate them, you have to commit to (and act upon) improving the state of IT capabilities. This is, of course, a good thing. Additionally, Shadow IT groups are often unwitting impediments to improving IT capability. If as CIO I don’t have the entire budget, then IT spend is sub-optimized. If as CIO I don’t have control of IT standards, processes and practices, then it is that much harder for me to improve IT capability. It’s not that some IT capability should not be embedded in the business – it absolutely should. But exactly what to embed, when and how to embed it are important questions that need to be thought through and the IT operating model properly “designed” (at least at lower maturity levels). Designing an IT operating model to be something akin to Swiss Cheese, where you have to design around the holes is not efficient, and is not a good basis upon which to drive an IT transformation.
Finally, there’s a “tough love” aspect to tackling Shadow IT groups. When I was a kid growing up in London, UK, I went to a school where uniforms were de rigeur, complete with school caps! (Long before AC/DC’s Angus Young showed us how cool they can be!) I was caught once too often without my school cap and was sent to the Vice Headmaster’s office for a dressing down. Fortunately for me, he was a wonderful man with a sense of humor, a Royal Airforce mustache and manner, and a vintage Rolls-Royce to boot! He gave me one of life’s great lessons – that it was not about wearing a school cap, per se, it was about setting and living within defined boundaries, so rebellious chaps like me could push against them without doing real harm. It’s like a parent disciplining their children – if the discipline is absent, the child will feel unloved. (Of course, too much discipline is even worse!) Anyway, when the CIO (with appropriate air cover from the CEO and executive team) announces that all IT will be managed under a single IT budget, and all IT-related resources report to the CIO’s organization, this sends a message to the firm – we are raising the bar on IT! People may not like it, but they will like the fact that someone is getting serious about improving the performance of the IT function. I’ve often seen situations where the predictions of “Oh, this will create a real stink and lots of resistance!” was far from what actually happened. Instead, people said, “About time – please take this group back into IT – its where they belong, and where they will have the best growth and career opportunities!”
So, if you have a Shadow IT problem, don’t be a wimp! Tackle it head on as an integral part of your IT transformation plan. Be ready for the noise and resistance, but don’t let it derail you!
Filed under: IT Maturity | Tagged: Business-IT Governance, Business-IT Maturity Model, shadow IT
In this case of IT, where does Application Support lie in the organization? We have application support (how do I do XYZ in an appplicaiton? I need a new company set up in application XYZ.) reporting up to “Accounting”, while the Application Development (make these code changes, write these interfaces) rolling up to IT.
I would not consider us a very mature IT company, btu this divide in application support vs. application development seems to work “OK”. Some times we march to the same beat, and other times we do not.
Your thoughts?
Dave
Great question, thanks! I think there are several issues wrapped up in this – let me take them one by one:
1. Should application development and application support be together?
There’s always an “it depends” aspect to this, and no organization model is perfect for all time. In fact, it has been said that every organization design contains the seeds of its own destruction, which is why we tend to see the cycles of centralize-decentralize. With those caveats, when development is constantly interrupted by support needs, productivity and quality suffer, so there is an argument to keep them separate. Having said that, cycling people between development and support groups (i.e., developers take a turn supporting what they’ve developed) is a good practice.
2. Should either application development or application support be located in the business rather than in an IT organization? There are arguments for locating support in the business, though this is not the most common practice. Having said that, we have to be careful in defining what is meant by, and what is the scope of support. I think of support as being strictly about helping users to use a system effectively, and dealing with bugs and fixes. Anything beyond that is development. This is an important distinction as “support” has a way of becoming a back door into development – a quick way to get stuff done without going through the disciplines common to a development organization. This is a slippery slope and usually ends up in “tears before bedtime” as my wife likes to say.
The other issue is tiers of support – Tier 1 typically means basic handholding, Tier 2 means some level of real problem solving and analysis, and Tier 3 means deep problem solving. It makes a lot of sense to put Tier 1 in the business – if possible, even turn it into a self-service model. Tier 2 is typically in IT but separate from development, and Tier 3 is often in development.
I think there are rarely good reasons to put development in the business, except for high maturity organizaitons, or if the development needs of a given business unit are TRULY unique (i.e., not just becasue the business likes to think they are different!)
Having said all of that, if you really are lower maturity, I’d be inclined to centralize as much as possible under IT so as to deploy good practices, common methods and disciplines, and look to migrate those things that can be migrated later on, once those disciplines have been internalized.
[...] and the Value Disciplines Posted on July 24, 2008 by itorganization2017 My recent post on Shadow IT: The Good , The Bad and The Ugly solicited an interesting comment about organization design and the placement of application [...]
[...] is a significant “non-formal” – i.e., shadow IT spend that is outside the IT budget. Shadow IT typically occurs as a natural response to a void [...]
I found your site on technorati and read a few of your other posts. Keep up the good work. I just added your RSS feed to my Google News Reader. Looking forward to reading more from you down the road!
pic is superb
[...] Vaughan Merlyn has a few great writeups about this force in the IT world, but this piece provides some clear [...]
[...] you with cleansed and understandable data , you’ll be faced with integrating external or shadow-IT data (probably one of the main reasons why PowerPivot appeals); again you’ll either need IT [...]