How timing change cuts costs

Recently, I came across a white paper that arguing that at its heart, the IT department was all about change. It contended that most costs in IT essentially relate to implementing change and the subsequent management of it. Moreover, the article stated that, since many of the ITIL processes relate to IT change in its many manifestations, by helping an organisation better manage such shifts, it is possible to use change metrics to determine the ROI in the implementation of ITIL. The article was the result of a brain storming session among a group of American CIOs who were looking at how they could argue an effective business case for the adoption of ITIL. The discussion highlighted that where IT staff members spend their most time usually revolves around change. The CIOs recognised that when something goes wrong, the resolution typically begins by focusing on what is different. The CIOs then agreed that it is possible to quantify change in IT operations through three key variables: the number of requests for change (RFC); the number of changes actually made and the number of releases that are implemented (a release was defined as a batch of changes grouped together that entailed build, test and implement processes).

Tracking changes to measure cost

The CIOs then examined five ITIL processes which address change. These are: change management; release management; configuration management; incident management and problem management. In each case they saw that the amount of work implementing these processes, and the amount of costs incurred, related to either the volume of requests for change, the number of releases or the amount of change projects underway. As such, the paper argued that if an organisation could track the number of these activities, it could build a model based on this data and determine how much it was costing the business to undertake these tasks.

However, as a starting point, the CIO brainstorming session believed it was important to determine the key characteristics of organisations that were operationally efficient with IT. The group identified four elements: the frequency of change; the percentage of change happening outside the change management process; the number of people with responsibility for implementing change and the percentage of total changes that occur in the last third of the change control window.

Change vs efficiency

The CIOs saw a direct link between the frequency of change in IT and the operational efficiency of an IT department. They believed that organisations at the bottom of the efficiency curve have changes happening continuously. As such, the first step towards operational efficiency was seen as the implementation of weekly change windows which are the times in a week that are set aside for the implementation of any system modifications. Moreover, the CIOs believed that if an organisation could move to monthly change windows then this would generate even more cost savings.

However, the discussion also highlighted that, while many organisations believed they had established change control windows to manage change activities in IT, many modifications in the IT operations were still happening outside these timeframes. The CIOs appreciated the difficulty IT staff have in juggling conflicting priorities. When a service is unavailable, employees are under intense pressure to restore it as quickly as possible. As such, there can be a strong temptation to bypass the change control window and to implement ad-hoc changes. In addition, in many organisations the controls and documentation required by management can be so cumbersome that many people seek to work around them rather than use them to get their job done. The result is that this informal implementation of change is usually the cause of an increase in incidents and problems down the track, often because these changes go unrecorded.

Good change practice

Furthermore, many organisations try and cram a large number of changes at the end of the change window. Good practice usually entails introducing change in the first third of the window, testing change in the second third and, if there is a problem, to back out the change in the last third of the window. However, things tend not to go so smoothly in the real world. Often a project starts falling behind schedule and the response is to increase the number of changes introduced into a change window. Typically these are introduced in the last third of the window when the realisation dawns that the project is running late. However, such changes are usually the source of future difficulties.

Encouraging self-regulation

The CIOs considered that there were four steps in implementing ITIL to address these challenges. Firstly, there is a need to measure the amount of change happening in his organisation. This highlights the extent of this activity and will allow the IT department to suggest how to improve the efficiency of these changes. Next, the need to quantify the amount of informal changes being undertaken. The CIOs believed that revealing the extent of this work, and its potential for future problems, encouraged self-regulation of it, by employees. The third step was to diarise the changes made across all the IT equipment as this reveals what is happening on a given set of servers. ITIL requires IT staff to modify the way they work and the need for this can be a hard battle to win.

However, the evidence to support such changes in work practices can be provided by documenting changes and assessing their future impact on the IT operations. The final step was to encourage IT employees to self-regulate their change management activities. It believed that this was best achieved by allowing them to see how a better approach to change management, through the use of ITIL, can save their business much money and personal frustration, over time.

Valuable takeaways

The first of two valuable takeaways I found from this white paper was the need for CIOs to impress on their business counterparts that in IT, change costs money. The business must first distinguish between changes that are essential and those that are not, to derive savings in IT operations. The other takeaway was a recognition that while the business is constantly looking for greater operational efficiencies, this can be achieved by more avenues than closing down projects or making staff redundant. In particular, if IT can be more effective in how it handles change, then the IT operation itself will be able to deliver much more to the business.

Peter Hind is a consultant with many years of experience in the IT industry.