...using the principles of operational excellence for IT

The first two blogs of this series examined how we can design from the outset for operational excellence, when given the luxury of doing so, and then moved on to see how we can leverage existing data sources when we don’t have that luxury.

In this final blog, I’d like to see what lessons we can learn within the IT department from how the business improves itself using agile operational change. There are many opportunities for IT to use their own product (namely ‘data’), to make savings and realise rapid return on investment.

Firstly, let us examine the common challenges many IT departments are currently facing:

• They are under cost optimisation pressures

• They are not following continuous improvement cycles, as they are culturally difficult to adopt and require effort and budget to establish

• They are aware of most of the risks, regulatory issues and inefficiencies they run, but find them difficult to measure or quantify, and therefore to ‘sell’ programmes of improvement to senior management

• They have a feeling that there are more risk, regulatory issues and inefficiencies than they know about, but they sometimes lack the impartiality in order to discover them

If these challenges are familiar to you as a senior IT professional you should probably go and talk to your operational customers, as they will be working under the same challenges, but are already taking steps forward using approaches such as; independent risk assessment and Agile Operational Efficiency, and there is much to learn and apply from such techniques.

However, ‘spend-to-change’ budget is becoming increasingly hard to come by, so any changes have to be self-funding; hence the move to smaller, more agile incremental change. We often do this by creating our own ‘backlog’ of user stories regarding technology debt, which we remediate over time as new functionality is released.

In most financial organisations it’s very hard to implement agile change without a business driver, as it carries such a large overhead in testing and deployment. What we can do however is create good funding cases for moderately sized initiatives by quantifying risk and inefficiency in ways that those with both influence and cash can appreciate, and once agai that is all about the data.

Looking at the data sources mentioned in my previous blog, including: monitoring data, logging data, trace data and audit trail data, we should be able to build a cost model for incidents, outages and support costs for outdated platforms, both in terms of people and the charges incurred by suppliers and other infrastructure functions.

In order to get more serious funding we need to pitch to our senior sponsors in an effective way, and to instil the correct level of fear about technology debt, obsolete systems, knowledge risk and non-compliant processes. For example, as part of a previous ‘right-shoring’ exercise we’ve looked across a clients’ portfolio and demonstrated the gap between the risk level they were running on their legacy platforms (and what would be considered acceptable), before considering a nearshore or offshore alternative support model.

Essentially, it was necessary from an operational risk perspective and surprisingly cost effective to get their own house in order, rather than hand over problems which may only get worse in future, no matter how attractive the initial cost may seem.

We examined ways of formalising and quantifying the approach to assessment while visualising the results in a business friendly way. Helping IT improve itself is certainly one way of helping the business demonstrate its own ROI, as at the end of the day the business pays for IT; and whether we like it or not, will therefore expect visible and ongoing value for money.

In conclusion, this series has focussed on the necessity for IT and Operations to achieve excellence together, and the importance of leveraging the correct data and learning from it in the pursuit of such a goal. It is crucial to understand how the IT function can assist and help operations in their efforts to increase efficiency in an agile way, and also seek to help itself by “eating our own dogfood”, effectively practicing what we preach.

For those who can remember as far back as 1989, some wise men once said ”be excellent to each other”; for IT Operations these are certainly wise words indeed.