Today I read the latest Norwegian issue of Computerworld (nr 5 2009, pg 6), and to my great pleasure I found an article from our Senior Gartner columnist about the “war” between the IT Organization wanting to standardize and the vast amount of different quick win business applications that the business side want to use right away. These two agendas just does not match. Who wins; the IT department or the business side? And what happens with the IT department if they always loose? And what happens to innovation if the IT department always win? Gartner predicts that individual system choices will be more and more common. This, to my delight, foster creativity, but it also makes defining a complete IT Architecture nearly impossible and to manage, and if I may add, IT risk even harder to manage. The suggested solution: managed diversity.
I am a follower on the IT Strategy blog by Raj Sheelvant where he earlier wrote about rebranding the CIO, meaning the CIO could be an enabler instead of a brake in the organization.
Imagine a CIO fully grasping this concept? I certainly think an CIO coming to me and saying, use whatever program, as long as you tell me, and you try to convince the others doing the same as you to use the same program, would give me positive feelings. Now, how to make this work in practice? I think it is possible to sum it up in four very clear actions/policies:
I absolutely think the Gartner approach where one may has to pay “internal money” in order to deviate from the given IT standard gives meaning. This not only incentivizes the business side to choose the preferred IT Standards, but it also enables the IT Department to provide some supporting resources to the new choice of technology if they should choose to deviate. It raises the question of how to price this though, but that is a whole other discussion.
Taking the consulting role
The CIO is no longer in charge of just operations of his system portfolio, but to give the business side good advice on how their choices of technology will work. He may ask questions like “how is backup taken care of” and “who do you call when it does not work” and last but not least “how is it integrated with our other portfolio of systems”? The CIO will have to “sell” the benefits of his policy, and enabling the organization to make informed choices. This is totally the other way around, opposed to the more or less undocumented denial one sometimes meet.
Make sure to define clear system policies that enables individual freedom, but keeping the necessary level of control. This must mean that applications used at work should be approved, so the IT Organisation knows about it, but that denying people to use it, given that they can pay for it as in the first bullet, is more difficult.
Dealing with the lifecycle cost and risk
To be aware of the lifecycle cost when enabling a new tool is critical. The feeling that deviation from the standard creates higher costs later, may also be why the CIO seems negative in the first place. Often quick and dirty projects only thinks about getting the tool up and running and forget about maintenance, backup, access control, security and so on. These issues must be tackled in order for the new tools to meet a long and prosperous life in the organization.
Any comments to these four elements? Anyone missing?
IBM illustrated this new role at their CIO Conference in November 2007 like this:
Good luck CIOs!