Combining projects and good management

By Andrew Clifford

We need to change how we view IT so that we can run projects without undermining long-term management.

IT's emphasis on projects is a source of immaturity. Projects are one-off and special, they cut across organisational boundaries, they deliver value by meeting broad organisational aims, and they are time critical. This is the opposite of mature IT, which is standard, has clear ownership, focussed purpose and is managed to be long-lived.

The conflict between projects and long-term management is one of the facts of life of IT. It would be stupid to get rid of projects, which are the best way of making step changes that take business forward. It would be naive to retreat into a technically-focussed role, and refuse to take a proper role in business projects.

How can we modify our approach to managing IT to better balance the need for projects and the need for reliable, well-governed and long-lived IT?

The key is to make IT more simply understandable to business. If we only talk about IT as a business enabler that supports business processes, this does little to help us (both inside and outside the IT department) grasp the management requirements on the IT itself. We need to communicate some of the management realities of IT, and show how this relates to business use.

We need to present IT not as business enablers or technical layers, but as a simple set of "systems". A system, by this definition, is a set of IT capability with clear purpose, boundary and owner. You can think of a system in terms of its responsibilities, which is what it does for its owner and which are always a subset of the owner's responsibilities.

This way of defining systems gives you something on to which you can map project requirements, and about which you can discuss qualities such as reliability and longevity. Instead of structuring IT work solely by project, each system can have its own development plan, built from the requirements from multiple business projects. Because systems are more clearly owned, business managers are more aware of the trade-off between urgent project requirements and long term good management. Because the responsibilities of systems are better known, and subset the responsibilities of their owners, it is easier to properly critique how a project alters the responsibilities of and value delivered by each system.

This approach alters the role of the project manager, taking them away from the role of technical task leader, to a proper role negotiating and co-ordinating multiple changes. This approach also values the role of business analysts, system analysts and architects who can creatively translate requirements into changes to existing business responsibilities and systems, which is much harder but also much more valuable than designing a new solution and only later thinking how it fits with what is already there.

Importantly, this approach emphasises that IT projects should nearly always be incremental. Too many of our methods and our IT culture sees our job as taking out the old and putting in the new. But as IT matures, we have to change this. We have to see IT projects as strengthening and building on what is already there, not knocking it down and starting again every time.

Subscription