In Circumventing the CIO - What's the Harm?, Andy Blumenthal enumerates some of the potential issues when technology is introduced outside of normal IT channels.
In simplest terms, what Andy describes is a classic conflict between IT and the rest of the company. To complicate matters, the ever increasing consumerization of IT makes it easier to bypass the traditional list of project hurdles imposed by most IT organizations.
I am, however, somewhat dismayed at the list Andy provides. Despite his reminder about striking a balance, the list might lead one to believe that there is no room for risk in business. On the contrary, business is about managing, sometimes leveraging, risk. It is perfectly reasonable to expect that business can tolerate a certain amount of non-compliance to the risk aversion common in IT. In fact, there are circumstances where it must be part of a core business strategy. The key, as always, is to ensure the level of risk aligns with the needs of the enterprise.
If the level of non-compliance is out of alignment with business needs, the problem still reduces to one of conflict, rather than non-compliance. Regardless of whether IT is overly strict or the user is overly cavalier, the conflict is best served if IT starts adopting a posture more in line with basic conflict resolution/management/transformation concepts.
To be fair, Andy works in an industry familiar with bureaucracy and the command-and-control model. At the same time, it seems all IT organizations incur another type of risk if they do not allow a certain amount of free movement around the edges.
(Bonus points for fostering and participating in that free movement around the edges)
Sunday, October 21, 2007
New House Rule: Non-Compliance is now Mandatory
Subscribe to:
Post Comments (Atom)
2 comments:
Innovation is a good thing, and if a business unit can budget what, for it, is a small portion of its R&D budget to prototype a new way of doing something, prepare a report, do a presentation or a mailing, or do some analysis, these are all things that don't require constant handholding by a central IT staff.
On the other hand, if a project involves a new business process or a substantial change to a business process, involves strategic company data, has data security or financial control considerations, then the IT group should budget to have a few talented business analysts that should make available to business units to support but not necessarily control these ad-hoc projects.
In the same vein, a technology acquisition by a business unit should take advantage of the expertise, and possible discount purchasing power of the IT organization.
This doesn't mean that business units can't have a certain amount of discretionary purchasing power, but that freedom needs to exist within some reasonable boundaries. Certain areas affecting security, enterprise infrastructure, strategic systems, and compliance, require control or oversight by IT.
This can be accomplished by setting a policy defining areas where business units can manage their own technology initiatives and which areas. On one hand, the business units will know that they have freedom to act within those boundaries, and will have no reason to hide "skunk works" projects from IT. On the other hand, the IT organization should be advised of intended acquisitions or small projects, and should have a process where they are required to fast-track a quick review of them, providing feedback only if they represent a serious risk. Otherwise IT would not have veto power over acquisitions or projects within a business unit's discretion.
Maintenance, network management, security, shared services, and help-desk operations generally fall under the IT department's responsibility, and for that reason, there is usually standardization of hardware, an approved list of software, and, to the extent possible, standard configurations that have been tested and which the IT organization is trained to support.
This standardization strategy allows IT to quickly set up new systems, maintain an inventory of spares, and easily swap out failed systems and components with a spare and diagnose, repair, or discard the failed ones.
When a business unit acquires non-standard hardware or software, it cannot expect IT to be able to provide spares or be able to resolve problems as quickly as if standard systems were deployed.
Again, this is why business unit discretion should be defined within limits that take these issues into consideration without totally handcuffing the units.
The leaders of an enterprise need to establish the ground rules, encourage cooperation, and provide a forum for resolving the inevitable but hopefully rare cases where someone has to decide whether something falls on one side or the line or the other.
Very well put. The conflict management component should contain avenues for the product introduction of new ideas and alternative solutions.
I've had success providing channels for "monitored variance", in which the technology is encouraged while still being required certain deliverables. It's often an easy sell to all parties involved. It's definitely easier if the central IT organization has an R&D function.
Post a Comment