The blame game

If everybody does exactly what they are meant to in a project, and delivers on time and to budget, the project is almost certain to fail.

Project failure is endemic in IT. Something like 70% of all IT projects fail, and we constantly ask ourselves why.

A large part of the reason is the inherent complexity of IT projects. The technology itself is hard enough. But we also have to deal with business change, organisational politics, and resourcing the project with suitably skilled staff.

We do what we can to manage this complexity. We employ experienced project managers and designers. We draw up plans. We set objectives and budgets. We monitor and control.

But then I think we make a fatal mistake. We believe the plans.

The plans we have for an IT project are only ever a pale approximation of what we need to do. In all but the simplest of cases, IT projects require a huge exploration of the unknown. The design, the process, the business context, the political landscape, all evolve as the project progresses.

Unfortunately, we seem to be driven to the opposite mindset. As soon as we have the first whiff of a plan, it is set in stone. And then, as if suffering from collective insanity, we act as if the project plan is perfect, and the project will only fail when someone makes a mistake.

This is the start of an elaborate blame game.

As soon as there are any problems in the project, or even any positive developments that could take the project forward, then the certainty of the project is threatened. Rather than responding positively, every disruption is seen as a problem. Every problem must have a cause. It must be someone's fault.

But this is such stupid thinking. Projects do not succeed simply when nobody makes a mistake. Projects only succeed when everybody exceeds the requirements of the plan. We need to do more than the defined tasks. We need to change the design time and time again. We need to take on more responsibility. We may even need to take more time and spend more money. We need to avoid laying blame on others, and respect that they too are struggling under difficult conditions to get the project to succeed.

We need people who can work in the demanding, fluid environment of IT projects. Who can work from and contribute to an evolving view of the project, and are not deluded by false certainty. But the culture of blame drives the opposite behaviours. It drives a work-to-rule mentality, where people will not work beyond the plan. It drives dishonesty, where important issues, even positive developments, are hidden. It promotes those who are wiley and thick-skinned and enjoy the blame game, rather than the quietly competent who can make the project truly succeed.

Avoiding a blame culture is the opposite of avoiding blame. We need to realise that we can never be entirely certain, and that a responsive and flexible approach is more valuable than slavishly following the plan.

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

The last big problem

The ongoing management of legacy systems is the last big problem in IT. It requires a level of co-operation that we have not yet achieved.

In IT, we know how to do most things. We know how to write programs. We know how to design systems. We know how to manage projects. We know how to deliver services. There are problems, and there is room for improvement, but as an industry we understand the problems and have got solutions to meet them.

The one area we have not to got to grips with is the ongoing management of the IT that we have. We often call these "legacy systems" - the legacy that the previous generation of managers and designers left with us.

People agree that there is a huge value in better management of the IT that we have. It eats 70% of our budgets. It is a major source of risk. It is the starting point for all new work. It stops us responding quickly to business change.

In other parts of IT, we know what to do. But when it comes to the ongoing management of legacy systems, we just do not know what to do. Or rather, there are a number of competing viewpoints for how we should approach it.

I can see at least five different IT disciplines that have to come together.



We need to be better at IT alignment and strategy. A lot of IT strategy is so focussed on business change that we undervalue the IT that we already have and the role it plays in delivering value every day. We need to understand how to align our long-term management with business objectives, to make the case for the investment that we need.

We need processes. These need to go beyond the day-to-day service delivery processes, and include processes for the identification, justification and execution of preventative maintenance.

We need information and analysis to guide our decisions. I split this into two: top-down, management information to inventorise and assess IT and identify priorities. We also need the bottom-up, technical information that you get from discovery tools such as code scanners.

Underpinning this we need a thorough record of all the architecture and configuration of our IT.

We know the benefits of tackling the problems of better long-term management. We see the value of our own piece of the jigsaw. But in our enthusiasm, we overemphasise the value of our own piece in isolation and underemphasise the value of working with others.

I include myself in this criticism. Our system quality management approach and Metrici Advisor tool help with the inventory, assessment and prioritisation area. I am enthusiastic about it because it is the area that is least developed in most organisation.

But I need to work with others too. Tackling legacy systems needs better IT strategy. It needs new processes. It needs tools for discovering the IT that we have. It needs architecture and configuration.

There are huge rewards for better ongoing management of our IT. We need to work together to reap them.

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

Tidying IT

You can learn a lot about managing legacy IT from tidying your home.

I am not a naturally tidy person. I tend to leave things where they are when I have finished with them. My desk collects clutter. But over the years I have learned that having things tidy makes life a lot easier, and out of necessity I have developed some rules for tidying effectively:

• Everything needs a place. If you do not know where something belongs, you can never keep it tidy.
• Tidy the worst first. Tidying can go on forever. You need to develop a good eye for what is really untidy, so that you get the best effect for the least effort. If there is a mess of snacks and drinks on the table, tidy that before alphabetising the CDs.
• Do a proper job. When you have picked something to tidy away, put it away completely. Merely sorting things to be tidied later just makes more work.
• Have a method. It does not have to be complicated, but it should show you what to do next without procrastination, and let you see progress.

I have also learned that you can not tidy everything at once, and abandoning a big sort-out half way through can leave things more untidy than when you started. My favourite method for tidying is very simple: find something that belongs somewhere else; put it away; repeat. It is not sophisticated, but it means I can stop tidying at any time without things looking worse, and it is easy to start again.

There are lots of parallels with tidying and the management of older "legacy" IT systems — IT's equivalent of a messy house.

Some try to avoid tidying their IT by buying new packages. This is like moving house. It is a lot more expensive than tidying what you have, and inevitably you just take the mess with you. You can get someone in to tidy for you, but that does not stop the mess from having to be sorted.

To sort out legacy systems:

• Define strategy and policy. This is the IT equivalent of knowing everything's place. Knowing that a system is running on an unsupported database is not enough; you need to know what you can support.
• Prioritise. You will make more of a difference and spend less money if you tackle the most important things first.
• Provide resources. Tidying is not just a management exercise. It requires actual work. You need to commit resources to fixing things.
• Have a method. It does not have to be sophisticated, just something that gives you guidance, shows progress, and lets you stop and start the work to fit in with other commitments.

These ideas about tidying have had a strong influence on the SQM method. SQM provides a practical way of defining strategy and policy. It sets priorities. It guides you what to do next. It shows progress. It lets you tackle the mess of legacy systems without committing to huge and risky transformation projects.

It is a new year, a good time for making resolutions. Make 2010 the year you tidy up your old IT.

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