Breaking free from the tyranny of time

This is quite a long post so here is the 30-second version:

• organising services around calendars and clocks is generally a bad idea
• it is much better to organise around outcomes and risks
• this is now a practical option because of new technology
• CIOs can take the lead and help the whole enterprise.

Sarah Wilkinson, CTO for the UK Home Office, recently wrote a post about breaking away from some long held traditions in IT. The article includes some great advice but I think we need to go further.

Sarah explains that setting a single, arbitrary timetable for strategy and other IT processes creates issues because the pace of change varies across different parts of an organisation and over time. She suggests that CIOs should monitor what is going on and keep resetting the timetable for IT Strategy to fit. This is better than the traditional IT approach but why not drop the timetable altogether? Leading organisations are shifting away from operating according to predefined procedures and set routines and, instead, are providing more flexible services which focus on outcomes and adapt to risk. We should do the same for IT.

Abandoning the routine

Here is a simple example to illustrate the differences between these ways of operating. Imagine your organisation conducts routine annual checks of health conditions. The checks might be needed to make sure a health-related service is appropriate or a health-related insurance policy is still valid. These routine checks will be prone to all sorts of problems. Some people will have long-term conditions which are unlikely to change a great deal in the course of a year and so some of these checks will waste time and can cause unnecessary distress. Other people will have short-term illnesses which might be resolved in weeks. The checks will still be a waste, because they will be far too late, and the organisation may be devoting resources to the wrong people or missing the opportunity to switch to more appropriate and more valuable services. In effect we are using a calendar as a proxy for someone’s health and it is a pretty poor proxy. This isn’t a question of speed - a stop watch would also be a pretty poor proxy - it is a question of efficient access to information.

In the past an annual check might have been a reasonable compromise between delivering the required outcomes, mitigating the risks and keeping the cost of services under control. However, cheap, mobile, consumer IT makes it possible to obtain better information and take the appropriate action - almost in real-time. Soon more wearable technology and connected sensors will shift the balance even further. For instance, we might track some health indicators in real-time and change our services instantly to keep in step. Even when we don’t have access to real-time information we can keep track of the level of risk and act accordingly. For example, we can estimate the likelihood of a change to someone’s state of health and the impact that this could have and initiate a proportionate check when the risk reaches a certain threshold. When we do act - triggered by the risk not the calendar - the type of check we perform can also be chosen based upon a trade-off between the cost of the check, the likely value of what we will find out and the impact upon the customer.

Look in any type of organisation and in their component parts and you will find activities driven by procedure and routine which could be transformed to be driven by outcomes and risk. Think about annual performance reviews, budget setting, infrastructure maintenance, equipment replacement and pretty much any type of service contract. Some of these examples can have enormous implications for society such as the way age drives education and retirement. Many businesses and parts of the public sector are aware of these opportunities and are developing new ways of working. What can we do in IT?

Risk-based IT

As Sarah points out there are some IT activities which have traditionally been driven by arbitrary timetables which we could operate in a much more flexible and effective way by focusing on outcomes and risk. As an example, we could maintain a strategy dashboard or heat map and focus our efforts on the hot spots where IT services are not keeping up with changes in the wider business or are not making the most of new technology developments.

A bigger prize (by a factor of between 20 and 100 depending upon the type of business) is the opportunity to provide the information flows, decision tools and automation to make business operations and customer services more responsive to outcomes and risks. In practice, we will normally need to progress on both these areas in parallel. An IT function working to fixed procedures and routines will find it very difficult to provide the IT services which an agile, risk-based business will need.

Since we are not all doing this already there clearly must be some obstacles. Probably the biggest is that humans are demonstrably bad at dealing with risk and uncertainty. There are plenty of studies which show that we repeatedly make bad, and even irrational, decisions when faced with uncertainty. There are some fun games you can play in workshops and training situations which can show that even highly trained project professionals can be hopeless at assessing risks. When smart people develop tools to help us address some of these problems some less-smart people often miss the point and abuse the tools. If you have ever attended a risk review meeting for an IT project you will spot plenty of examples - think about why this group of people meet every week to review risks which are then ignored until the next meeting. Occasionally these problems defeat even the cleverest people - try setting a workable risk appetite for your organisation or work out the expected impact of the next flu epidemic.

My suggestion to CIOs is to start immediately and find an easy target to introduce a risk-based approach. For example:

• Look at the next investment proposal which you receive and make the case for including some elements of risk-based working.
• Halt one of the cyclical IT processes - say architecture or strategy - and allocate effort based upon an assessment of operational risks.
• Rank the sections of the IT business plan and start reworking the parts which are most out of step with business needs.

These first steps might not be the most transformational things that you can do but they will grow the awareness of your peers and team members, start the culture change that is needed and provide some track record that you can use to learn and grow.