Embracing steady state

By Andrew Clifford

It is time to move away from the big distinction between steady state and projects.

Enterprise IT is split into two. On the one hand we have changes and projects. On the other, we have steady state, business as usual.

We split IT specialisms along these lines. Support, operations, system administration and security are generally managed as steady state activities. Analysis, design and programming are generally managed in projects.

In many respects it is a very reasonable split. It recognises the work required to keep things more-or-less as they are, and separates this from the work required to take leaps forward in capability.

It is a common pattern, too, even in nature. Evolutionary biology recognises the idea of a "punctuated equilibrium" - periods of more-or-less steady state punctuated occasionally by periods of more rapid change.

Despite its obvious appeal, I think the big distinction between steady state and projects is now becoming a barrier to cost-effective IT.

Years ago, many IT projects introduced fundamentally new ways of doing business, or gained benefit from fundamentally new technologies. A colleague of mine was very much involved in the initial adoption of IT in fashion catalogue shopping. This is a relatively complicated business model, in which women (it was nearly always women) acted as agents to sell clothes on credit to their friends and neighbours, then collected the money in instalments over the following weeks. It was a huge business, but relatively complicated, with suppliers, agents, credit agreements, home delivery, returns, catalogue production, and so forth.

The introduction of IT had massive impacts in clerical, financial and logistical support. As he described it, any afternoon you could dream up a project that would save a million pounds. Given the return on investment in new projects, the overriding requirement was to get new systems in quickly, and to keep them stable and functioning long enough to be replaced with a new system that would provide a similar huge return on investment. There was no point building longevity into systems - speed of development was everything.

If you look at a typical IT project now there is much less genuinely new capability. Small steps forward in business capability are hidden inside massive projects to replace existing systems that have become too hard to work with or which rely on out-of-date technology. Even though technology is cheaper and development faster, the return on investment is much lower because less new capability is being delivered.

The split between projects and steady state made a lot of sense years ago, and was an efficient way of gaining value from IT. As the incremental benefit of projects decreases, the split makes less sense. There is now more value in changing and improving systems incrementally, which requires changes to how we design, develop and manage systems. This would let us get away from massive change projects, which are now a less efficient way of getting value from IT.

I suspect the biggest barrier to this is that our perception of IT, the specialisms we have, our career paths and reward structures, are all linked to the strong distinction between steady state and projects. Our approach to management is stuck in an outdated "dash for growth" model. We need to embrace the steady state.

Subscription