Controlling departmental IT

By Andrew Clifford

You can achieve the alignment and flexibility of departmental IT, and still keep control and co-ordination at the centre.

End-user developed systems, or small IT departments within business departments, are often criticised by the central IT organisation.

• Support is ill defined.
• The architecture is "hopeful", often based on supersized office applications, not properly designed, documented, tested or kept up-to-date.
• Data is parochial, not normalised to the broader needs of the organisation.
• Data is ill-controlled: sensitive data leaks out, data is not properly backed up.
• The systems may be developed and supported by uncontrolled external contractors.
• Worst of all, the central IT organisation has to pick up the pieces when it breaks or when key staff move on.

But there are a lot of advantages to departmental IT.

• IT is clearly owned by the business, and closely aligned to needs.
• IT is responsive, and does not have to wait for the central organisation in order to meet new business needs.
• Cost are properly accounted for - the costs are born directly by the departments who use the systems.
• Resourcing pressure can be removed from central IT.

These advantages - ownership, alignment, responsiveness, accountability, resourcing - reflect some of the major problems in IT. Is there a way that we can have the advantages of departmental IT, without the disadvantages?

I think there is.

The obvious solution is to make sure that departmental IT is managed to standards that prevent the most significant problems. However, it is hard to enforce standards without co-operation. The detailed technical and process standards used to run central IT would be seen as too difficult, too technical, and disconnected from business needs, and would not be accepted. If we want to use standards to help manage departmental IT, we need a different approach that does not prescribe how people should work, but limits itself to the most important aspects of what has to be achieved.

Specifically, we need to:

• Focus standards on a small number of important points.
• Explain the business rationale for each part of the standards.
• Express standards at a management level, not a technical level.
• Express standards as outcomes, not processes.
• Provide a simple framework for communicating standards.
• Assess against standards in an open and consistent fashion.
• Provide justification for all work required to meet standards.
• Show that standards can evolve to reflect changing business needs.

I have been working on system quality management methods, and thinking how these could be used to control departmental IT. It certainly seems to fit: system quality management is aimed at the high-level management outcomes needed to ensure IT is meeting objectives, rather than detailed technical and process standards needed to run IT day-to-day.

Of course, it takes a lot of political skill to control departmental IT effectively. But there is a big prize to be won: the ownership, alignment, responsiveness, accountability and resourcing of departmental IT, combined with the control, co-ordination and economies of scale of central IT. A simple and effective standards framework, like system quality management, could bring this prize much closer.

Subscription