17 August 2010

Embracing steady state: how

By Andrew Clifford

Last week I suggested that we need to break down the big distinction between projects and steady state management, and that we should manage more as steady state. This week I describe how.

The need to shift from dash to growth to steady state

Most organisations have moved on from managing technical capability, to using projects to deliver changes as quickly as possible.

In reality, though, most organisations have matured even further. Most work in most projects involves replacing functionality, not delivering new functionality. Our management approach has not kept up, and we are still managing a dash for growth. To maximise the value from our investments in IT, we now need to change our management approach.

We need to present IT differently. During the dash for growth, there was a lot of opportunity for totally new IT. It was appropriate to use relatively simple and even emotive arguments such as "information is the life blood of the organisation" to argue for IT.

Now that IT is more mature, and the general case for IT has been made, we need much more precise discussions about optimising the use of IT, to separate truly valuable use from gratuitous use. We need more rigorous analyses of the business value of information, and the ongoing costs of using, running and maintaining IT. We may need to dampen the enthusiasms of our business colleagues for systems that can not deliver value. A down-to-earth view of IT, as a capability to automate the storage, transformation and communication of information, can help us understand value more precisely.

The main IT management focus needs to alter, too. When the emphasis was on growth, it made sense to structure much of IT management (and career structures) around projects.

Now that IT is more mature, we need to focus on the IT that we already have. We need to shift attention to the ongoing management of meaningful business systems, rather than overemphasise big changes. We need to move on from projects that implement new IT to incremental changes that continuously realign what we have to where business is going.

At a more detailed level, we need to design and develop systems to be long-lived and easy to evolve. We need to choose technology that can last a long time, and use it so that it can. We need to value standardisation more than productivity.

We need to design in a way that makes systems easy to work with. We need modular designs, but not so intricate that nobody other than their original developers can understand them. We need to adopt methods of connecting systems that emphasise ease of independent change, rather than development speed. We need to pay more attention to documentation and testing, because these are much more important when systems are long-lived.

Regular readers will recognise these themes: demand reduction, precise definition of IT value, system focus, incremental change, standards, simple design, decoupled integration, documentation, and testing. These are not as exciting as technology and projects, but they are what we need. We need to move on from our obsessions with yesterday's problems, and use these to tackle tomorrow's.