Road Closed Street Sign by Kevinrosseel at Morguefile.com

When IT is a Disabler

Law has many purposes.  For business, having laws means having some knowledge as to what might happen given a particular course of action.  That knowability is helpful, because it means you can plan and take into account possible risks or have particular expectations as to outcomes.  The same benefits can exist when information technology teams are clear about what and how they will support technology.  If they aren’t, they can inhibit an organization’s progress.

One of the functions that IT departments often champion is standardization of hardware and software.  It makes a huge amount of sense from a support standpoint and, as much as end users may be frustrated by it, it is often the most effective use of organization dollars.  But what if the IT department treats itself differently?  Newer versions of standard software, better hardware to run it.  Not based on work requirements, but based on org chart location.  That can cause problems.  There is the obvious issue of perception – why the self-serving benefits to the apparent detriment of other teams – but it is more than that.  New software versions usually offer improvements in functionality.  If standards are really important, then the new versions should be tested and rolled out to the organization, or dropped.

There are also the challenges caused by the one-off request.  A department needs to do X activity and it goes outside the standards.  The IT team needs to be flexible enough to figure out how to handle that.  Sometimes it requires the business unit to be flexible in how they ask for the flexibility.  “I need an iPad” may be acceptable if it is “I need a tablet” and then finding one that works with the organization’s IT infrastructure.  If the business doesn’t ask that question, the IT team should ask (like a good librarian on a reference interview) where there is flexibility.  Sometimes there isn’t any and the business unit should be able to underscore why a narrow choice is necessary.

At the same time, the IT team needs to be able to explain clearly the business reasons for not providing support.  This is particularly hard if they have allowed one business unit to successfully acquire hardware or software that is non-standard and then denies another, without any supportable business reason.  “Apple is terrible” or “We just don’t trust your staff” isn’t going to cut it.

This was an experience related to me recently by a colleague.  It makes it hard when you manage a business unit (and I have three functional teams all doing things with different technology needs) and need to get your projects off the ground.  If you can rely on the existence of someone else already does that so I can too, it means that you can move forward relatively easily.  If, on the other hand, every project that has a potential, no matter how minor, technology implication has to involve a meeting with IT managers (iPad purchase being a great example), then it slows down and, in some organizations, may entirely inhibit development of new projects.  Worst case, the business unit takes advantage of its silo and starts to develop its own IT group, operating outside the confines of the organizational IT structure.

There is a constant tension between IT teams needing to maintain control over their systems and business units with their own ideas on moving forward.  If the organization has defined its direction well, it can lessen this tension because both IT and business teams have some common understanding of what they should be working toward.  When IT has a good understanding of the organization’s business direction, and the flexibility to balance supporting business unit innovation and the very real limitations on its resources – time, money, and people – it can be an enabler, not a disabler, for the organization’s success.