Living wills

Living wills for IT systems, which explain how they need to be managed at the end of their life, would help us keep them running usefully for much longer.

The UK government has proposed that every bank maintains plans which explain how the bank should be managed if it runs into financial difficulties. The plan shows how the bank's assets can be sold, how its liabilities can be met, and how it can be wound up quickly. These plans, dubbed "living wills", would help regulators quickly assess a failing bank and stabilise the situation.

I have been wondering whether we would benefit from something similar in IT.

IT living wills are nothing to do with business continuity or disaster recovery. IT living wills explain how to decommission a system gracefully, for example:

• After mergers and acquisitions, when a system is no longer required because it is replaced by an equivalent system from the other party to the merger.
• When key technology or suppliers fail, and a system must be replaced because it is no longer viable.
• At the end of a system's life, when the organisation requires a system with greater functionality, a new technology basis, or fewer constraints.

One of the main contents of an IT living will would be a list of the business processes that are supported by the system, and other systems that take data from the system.

This would be difficult to document. The links from older systems are like spaghetti. Commentators have pointed out that banks will need to simplify their corporate structures so that they can write living wills. I see parallels in IT, where the need to record what a system supports would drive simplification.

An IT living will would explain how the business assets in the system, the information and business rules, can be recovered.

Most corporate information is held in databases. The data needs to be exported in a simple, understandable form that could easily be taken into another system, or even into a simple spreadsheet. A database dump will not do. The living will would have to explain how to resolve the complicated structures used inside the database into much more understandable business data.

Recovering business rules is really hard. Reverse engineering code would not be acceptable. We would have to maintain good written specifications of all key rules.

A living will would explain how the main parts of the system interact, and how they could be replaced individually. It would be easy to explain how to replace a database if you have used standard SQL, but impossible if you have used vendor-specific extensions.

IT living wills would encourage a lot of good management practice. They would force systems to have simpler connections, data and rules. They would help us spot technology dead-ends. Paradoxically, planning the end of systems will help keep them running usefully for longer.

But IT living wills go much further than just good housekeeping. Existing systems are a major constraint on business change, and living wills would force us to make systems easier to change and to decommission. If we really want to take business forward, perhaps we should start by planning how to turn off the IT.

© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Do you know what business you are in?

We are so obsessed with service and business focus that we forget the special role that we have within business.

"Service is our business"

I saw this slogan on the side of a car wash company van. It is a fine sentiment, and often repeated. Giving good service is a vital part of any endeavour.

But there is a bit of a lie in the slogan. I suspect that their business is actually something to do with car washing.

In IT, it is not just the term "service" that confuses us. We use the term "business focus" in a similar, vague, way.

I have two concerns.

First, terms like "service" and "business focus" are not precise, and different people interpret them in different ways. For one person business focus might mean making a land-grab to lead business change projects, to another it might mean publishing weekly help desk statistics.

Second, these sentiments can cover up vagueness about what our role really is. We can seem truly business-focussed, and give great service, but completely abandon the role that we should be taking.

I will give some examples.

I once knew an IT service department that had a business focus initiative. There was a poster and slogan competition. But I certainly had no idea what they meant by "focussing on the business". The job of an IT services department is to deliver IT reliably, at low cost, and at low risk. Doing that job well is surely business focussed. Working with your business colleagues to understand their needs and constraints is part of that, but you must never forget what you role in the business is.

I see the same problem in project management. Project management has become a political game: making alliances, managing expectations, getting close to the business customer. Fine, but at the end of the day your job is to tease out valuable requirements for IT and to deliver IT solutions that meet those requirements. In the name of business focus we have shifted toward business change projects, but taken our eyes off the underlying IT delivery. Rather than defining manageable IT projects, we embark on woefully unrealistic business-IT change projects that are doomed to failure.

How do doctors work? Building good relationships with your patients, listening to their needs, is important. But your job as a doctor is to diagnose and treat disease. Sometimes this involves giving bad news, or suggesting unpleasant courses of action, or changing courses of action that are not working, or telling the patient that you do not know what is going on. Any doctor who shied away from this would be abandoning their calling. But in the name of "service" we constantly hide reality from our business colleagues.

I am not suggesting that we should abandon the ideas of service and business focus. But these have to be pursued in a context in which we have a very clear idea of the contribution that we are called to make. Our role is to advise on IT and deliver IT solutions. If we forget that, no amount of service and business focus can redeem us.

© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Wrapping infrastructure and architecture 2: how

A management model based on systems and qualities provides a wrapper that makes IT infrastructure and architecture easier to manage

To make management easier, we wrap money, activity and service delivery in management models, such as budgets, projects and SLAs. We need to do the same for infrastructure investment and architecture.

We need to start by considering why we care about infrastructure investment and architecture. In the long term, these have a big impact on the value of what is delivered, on its cost and risk, and the ease with which new business changes can be accommodated.

We need a way of modelling this long-term value. It is not to do with "spending within budget", or "delivery on time and to budget", or "repeatable low-cost service excellence". A better model is to see IT as an asset, and infrastructure investment and architecture are ways of maintaining and improving the value of the asset.

It is hard to measure the value of the asset directly. It is hard to understand the business value of the processes an IT system currently supports, and to disentangle the contributions of IT from human resources, finance and so on. It is even harder to understand how the management decisions you make now will impact value in the long term.

The best we can do is to model long-term asset value by using a set of characteristics, or qualities, that act as indicators of likely long-term value.

To give an idea of practicalities, I will outline what we do in our Metrici ESQM method.

We do not deal with the whole of IT as a single asset. We split IT down into a series of assets that people recognise, typically using the granularity of business applications. We call these assets "systems", where each system includes all the technology, process and people required to deliver the services from the applications.

To establish measures, we agree a basket of qualities that are indicators of likely long-term value, and which are impacted by infrastructure investment and architecture. For example, we might consider clarity of ownership, ease of change, scalability, consistency with corporate standards. We also capture key management data such as strategic importance.

We assess each system against each quality. This gives a view of the likely long-term value of the assets, and shows risks and opportunities where infrastructure investment and architecture can have an impact.

This approach is simple and effective. It gives simple numerical measures. Because it is based on assets that people recognise (such as the "Sales System"), it is easy for business colleagues to understand. It shows which systems are good and bad, and through time shows which systems are improving and which are failing.

Importantly, this model provides the wrapper we need for parts of IT management that we find difficult. It wraps infrastructure investment and architecture using in a simple management model (systems, qualities, assets, value), and leaves the detail (server purchase, routers, architectural standards, systems design) to the managers involved.

It is not a perfect model, but neither are budgets, projects and SLAs. But it is a good-enough model that can improve the management of infrastructure investment and architecture to the levels of maturity achieved in other part of IT.

© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Wrapping infrastructure and architecture 1: why

Make IT infrastructure and architecture easier to manage by wrapping it in a management model.

What do we manage in IT, and how do we manage it?

We manage money. We negotiate purchases, raise orders, manage invoice payments. But at a higher level, we do not talk about individual purchases, orders and invoices, we talk about budgets. We use budgets to set spending limits and to control expenditure. We use budgets as a way of wrapping up money to make it easier to manage, leaving the detail of the management to the managers involved.

We manage activities. We plan work, assign tasks, manage resources, control progress. But at a high level, we do not talk about individual tasks and resources, we talk about projects. We use projects to wrap related work into meaningful units of change, making them easier to manage, and leaving the details of management to the managers involved.

We manage the delivery of services. We run operational schedules, run help desks, contract offsite services, purchase connectivity, and so on. But at a high level, we do not talk about schedules, staff, offsite services and connectivity. We use wrappers like Service Level Agreements (SLAs) to embody a set of service requirements and to manage and control their achievement, making them easier to manage, and leaving the details of management to the managers involved.

In each of these cases, we create a wrapper to help management. Instead of dealing with the detail, we create a management model that hides the detail. Budgets, projects and SLAs are not perfect, but they are much better than dealing with all of the detail all of the time.

Some parts of IT have not got wrappers. We have not got good wrappers for the long-term management of IT, for infrastructure investment, for architecture. To a small extent they are managed within other wrappers. But mostly, we try to deal with them as they are. We try to get justification for a new storage array, try to make a case for improving documentation, or get business sign-off for an enterprise architecture. However much we try to make these business-facing and high-level, we are stuck with trying to manage them naked, without a wrapper to make their management easier.

We need a wrapper for these other parts of IT. We need something that allows us to record requirements for them, and to manage and control these aspects, without getting into the detail all of the time. We need something that helps us have meaningful conversations with our business colleagues.

What should this wrapper look like? The other wrappers are high-level abstractions that represent the main thing that management is concerned about, but which can contain and structure the detail reasonably well. What sort of high-level abstraction do we need for the long-term management of IT, for ongoing infrastructure investment, or for architecture?

We need a new wrapper, separate from budgets, projects and SLAs, to help us manage these other parts of IT better.

Next week I will introduce what I think this new wrapper should be.

© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

The culture of dishonesty

IT project management is submerged in a culture of dishonesty.

I am a rubbish project manager.

I can define work, run teams and meet deadlines well enough. But when I have worked formally as a project manager, I have been decidedly second-rate.

After years of pondering my failure, I have concluded that the reason I am a rubbish project manager is that I am just too honest.

There are four parts of project management I struggle with: hiding behind formalities, false certainty, deliberate omission and not finishing.

I am no good with the formalities of project management: plans, resourcing, sign-off, change control. No sooner have I started on a project plan than I see problems with it, and take the project in another direction. I am very open, and discuss this with my sponsor, but I tend to forget to follow up with all the right formalities. When things go wrong, I have not protected myself enough, and I get the blame.

If I am not certain about things, I let on. If I am asked how long things will take, and how much they will cost, I say what I know. "Somewhere between six weeks and one year, somewhere between ten thousand and a million." I never give the sponsor a warm glow that they are dealing with somebody who can see the future.

I blurt out the limitations of the work. "We are just doing the integration, nobody is looking at the reporting." Get me to run a project, and you will get a big list of all the things I am not doing.

Although I mess up lots of things, I am OK at meeting deadlines. If I am given a firm date, I assume it is there for a reason, and focus on delivering the core of the solution on time. But as often as not, I miss out half of what they wanted.

I am not being facetious when I say that I am a rubbish project manager. I come across as vague, lightweight, blameworthy. Project management requires special skills of communication and brinkmanship, gradually coaxing commitment from the sponsor. Project management is a dance: I keep tripping over my neurotic honesty.

If you are a project manager, should you follow my lead and be more honest? No, not if you value your career. In most environments, you have to manage the truth and cover your back.

But if you sponsor or commission projects, or manage project managers, be on the lookout for dishonesty. Do not ask for certainty, and certainly do not believe it when you see it. Look beyond the project formalities, and ask "So what?" What do all those plans, budgets and procedures really mean? Ask the awkward questions, like when can the old system be decommissioned, not just when will the new system be built. Do not impose firm deadlines unless you have to, but if you do make sure the project manager knows it is real, and check they are managing to it.

We reap what we sow. If we want to improve on our dismal project success rates in IT, maybe we should start by being a bit more honest.

© Copyright 2009 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.