Systems need more than project management and architecture

By Andrew Clifford

Project management and architecture are two of the main tools we use to manage IT. To manage systems better, we need another tool that is simpler and more direct.

If we want to address many of the persistent problems in IT we need to govern the systems themselves, not just investments, change projects and IT services. What does this system governance look like?

Two obvious candidates are project management and architecture.

A lot of governance is achieved by managing the way we work. We add extra tasks to our plans to include relevant stakeholders and to put in appropriate checks. We measure effort, delay, cost and earned value. We carefully document our working processes, so that we can improve them.

This is just what we need to govern the IT change process.

But governing the change process does not address areas outside the change. It will not, for example, identify that the systems you are not working on are now running on unsupported technology.

Another approach we use is to model the IT itself, what we term IT architecture. Architectures typically model the functionality, data and links between the IT systems. Some go further, and document business processes, or the hardware that supports the systems.

Architecture can be a great tool for getting a detailed view of IT, but it is not a good management tool.

• It tends to unmanageable detail. You have carry out a lot of work and wade through a lot of information to "do" architecture.
• It emphasises conceptually interesting parts of the IT (like data, processes and flows), at the expense of the mundane but vital. How many architectures can answer the question "which of our critical systems has got an up-to-date disaster recovery plan?"
• It is not a management tool. Architecture can answer some of the detailed "what?" questions, but not the "so what?" Architecture does not tell what is good, what is bad, and what you need to do about it.

To govern systems, we need a new tool in addition to project management and architecture. The new tool must focus on systems themselves, not change. It must be simple and relevant to the needs of management, not a detailed design tool.

The core tool we need is a small body of high-level information that records:

• What is important about our IT systems. This is a series of criteria, each of which can be expressed in terms of its business significance (value and risk to the business), and in terms of the underlying technical requirements.
• An assessment of how well systems match the criteria, so that we can measure their compliance.

This information evolves through use. It can be used during projects to identify risks and understand how the work is likely to meet broader requirements. It can be used to assess and analyse existing systems to understand where risks and opportunities lie. It is an excellent basis for measurement and performance management.

This body of criteria and assessments, and processes around its use, is the core management tool we need to govern systems. Over the coming weeks I will show how this approach to system governance works and can deliver significant benefit to your organisation.

Subscription