Brunel University's Business Class: How to avoid IT project failure

In the first of a new series exclusively for silicon.com, Brunel University's Professor Robert Macredie and Dr Mark Lycett look into large IT project failure and ways to avoid it. Are users missing the obvious precautions?

The cost of IT project failure seems only to grow. A recent study by KPMG, covering 134 listed companies in the UK, US, Africa, Australia and continental Europe, reported 56 per cent of firms have had to write off at least one IT project in the last year as a failure. The average loss incurred as a result was about €12.5m, with the single biggest write off almost €210m. As KPMG concluded (and as many of you may have already experienced) IT project failure is "rampant". The question should be: What are we doing about it? Perhaps it is time to investigate the way we develop systems from the outset.

Businesses are constantly required to evolve, driving or reacting to market trends. IT exists to support business, yet IT systems are often static. They are large, monolithic beasts. Many companies face a tough task supporting a changing business. The information systems they have in place have often been developed with one specific function in mind and tend to operate on one specific platform. They have rarely been developed thinking about integration and compatibility. Traditionally, businesses deal with legacy systems by creating more legacy systems - building layer upon layer, creating an overly complex base for a system that will be extremely difficult to adapt.

Given this, it is no wonder that producing information systems today is so costly. Under these circumstances, development is much too slow for current business conditions. It's very risky, as it's hard to control, and highly unsafe, as there are many hidden failure points associated with exactly how to produce these systems.

As well as flexibility of IT systems architecture, business success depends critically on its intellectual capital. People are the vital ingredients of a successful IT system, yet they are often an afterthought in its development, either there to follow processes defined with little thought to how they actually carry out the work and/or as slaves to the technology that businesses embrace so eagerly.

First, most businesses rarely approach the development of IT solutions by bringing different people together to ask for their advice. Not consulting the end user for direct input on the way the technology is developed causes real problems – both in terms of system structure and cultural acceptance.

Equally, the belief that machines can and should replicate human intelligence is misguided and can prove problematic, as systems are often developed to automate activities better suited to human interfaces (personal contact). Trying to mirror the problem-solving capabilities of people in information systems can add lots of code to systems that could never cater for any situation. In many cases, about 70 per cent of the entire code of a system is there to deal with exceptions which occur so infrequently as to make the investment questionable.

What to do? We should instead look to invest in making systems 'lighter' and more agile. Asking people to deal with the exceptions by being responsive and reactive is, after all, what people are good at. This would also mean the systems would be cheaper.

The bottom line is that larger projects have a tendency to fail more frequently than small ones – there's more to go wrong. Given all this, it makes sense for companies to build small IT systems quickly and in a modular structure so that these can be integrated into a larger, cohesive whole.

Perhaps it is time for businesses to look at 'componentising' their technology architecture, not just individual systems, ensuring that their core applications are structured so they can be added and removed without affecting overall architectural integrity. This would ensure the business has the flexibility to react according to its environment.

The other question to bear in mind is: Do you really need this? If it is not broken, don't replace it. Sometimes what you have works well already, so instead of replacing it, integrate it with other systems.

There is a tendency for management to believe it is necessary to spend allocated IT budgets in order to be seen to require them in the first place. The decision to buy a large IT system is not always based on a sound business case and can be a reaction to a merger or acquisition ("Let's scrap it all and start again") or an emotive reaction, such as an unfounded fear of falling behind competitors.

Individual businesses have individual IT requirements and any investment made must take this into consideration. Companies need to ask awkward questions such as: Do we really need to change systems? Are the potential savings worth the bother? Where do things go wrong and are there recognisable faults? Is accepted wisdom getting in the way? Are some cherished ideas actually wrong and if so how could we do things differently?

Looking to the future, if simple, straightforward approaches - like our very own Fluid Business project - only provide a 1 per cent improvement, they could save KPMG's 134 sample businesses €16.75m in a year – a startling figure.

There seems no fundamental obstacle to why we cannot achieve better system flexibility but it is likely to mean a broader view than the larger technology and process-oriented ones we currently tend to embrace. Perhaps the overriding message should be to consult a large number of people and implement small IT systems.

Professor Robert Macredie and Dr Mark Lycett are leaders of 'Fluid Business', a groundbreaking research project within the Department of Information Systems and Computing at Brunel University. They will be writing for silicon.com on issues of technology and business over the coming months and can be contacted by emailing FluidBusinessTeam@fusepr.com. Or email us with your opinions at editorial@silicon.com.