Why do large IT programmes fail?


Cover of The Challenges of Complex IT Projects report

Cover of The Challenges of Complex IT Projects report

Pieter Lindeque FREng is one of the foremost IT troubleshooters in Europe. He is sent to investigate, support and recover large information technology projects when they go wrong. Following recent headlines about how millions of pounds are being wasted on large failed IT projects, Pieter was asked to write about his experience and suggest ways that future projects could be managed.

The Computer Weekly IT Expenditure Report for 2005 established that IT spend in the UK has now reached over £70 billion a year, with nearly half of this total being spent in the UK public sector alone. Against this background, it is alarming that significant numbers of complex software and IT projects still fail to deliver key benefits on time and to target cost and specification. Worryingly, Computer Weekly had established in a previous survey that a mere 16% of IT projects were considered successful!

The Royal Academy of Engineering/British Computer Society’s report, The Challenges of Complex IT Projects, contains a number of insightful recommendations on the need for mature processes in project and programme management, systems and software engineering, and change and risk management. This article will elaborate on some of these recommendations and make an attempt at identifying the root causes, the ‘architecture’ and the ‘engineering gaps’, before offering a number of possible solutions to mitigate the risks in future projects.

An untenable state

Cobbs Paradox states: "We know why projects fail,we know how to prevent their failure – so why do they still fail?" What makes an IT project unique? Surely many visionary projects in other engineering disciplines face similar issues? Witness the challenges faced during the Sydney Opera House for example.

  • The real difference is that most non-trivial IT projects end up in the untenable state of having to support a visionary business concept which:

  • requires significant business transformation yet to be documented by the business

  • demands a complete bespoke software development programme

  • requires highly complex integration with multiple, poorly documented legacy systems

  • tests the outer limits of technical feasibility.

Establishing the ground rules

New IT systems are often introduced to enable business change or to implement a grand vision of business transformation. It is common knowledge that it is hard to articulate the nature of an envisioned business transformation in precise terms. It is quite rare for this transformation to be modelled or documented in such a way that IT practitioners are able to interpret and translate into models of an IT system. To make matters worse, IT systems themselves are notoriously difficult to visualise and articulate to business leaders and users. This gap is often addressed successfully by package vendors, not necessarily because the package function is particularly good, but because they are able to provide an early visualisation of the target system.

One method we use when exploring a client’s needs is to produce a model office. We set up a number of different computers in a room, each one representing a different user role. There might be one for procurement, one for production, one for sales people, and so on. These computers are then configured to reflect their working practices. The users can then agree that it works for them or flag up when it doesn’t. This way we can flow-through the results throughout the rest of the design process.

The gap between the business vision and the intended IT system is the cause of many significant failures in IT systems development. It is the author’s contention that this gap is most often a mismatch between the architecture of the intended system and the business vision.

The architecture gap

It has been noted that most successful complex IT systems developments are founded on three interlocked facets of architecture: business architecture, application architecture (including data) and infrastructure architecture. The existence of these architectures is a necessary but, as explained later, insufficient pre-condition for successful systems development.

We often try to bridge the gap between business vision and IT through the formalisation and documentation of more detailed requirements. Unfortunately, this frequently results in a potentially dangerous skewing of the architecture gap. The reason for this is that the definition of the detailed requirements is most often left to individuals who themselves do not understand the business vision and, in many cases,whose very jobs are threatened by the implementation of that vision.

It is often the case that company leaders are too busy to deal with us on a day-to-day basis and we are potentially talking to those who have a vested interest for the status quo to remain. It is therefore beneficial to find people within an organisation who share the same vision and passion for change as the leaders and then get the senior management to empower them. In the public sector, procurement is undertaken alongside detailed, documented requirements, resulting in a dangerous dichotomy between the expectations of the business leaders looking for Commercial off-the-Shelf (COTS) packages to enforce best practice and the owners of the requirements who are seeking to optimise current practice.

The situation is not helped by the potentially significant cost differential between an IT project utilising COTS packages and one which delivers on the wishes of every user consulted in the requirements process. The stage is then set for spectacular downstream failure.

The engineering gap

Another root cause for the failure of IT projects is the perception that the software systems are infinitely flexible and lack constraints. The Challenges of Complex IT Projects report suggested that software is intangible; its boundaries are unknown.

A quote in the report says: "If I was a managing director trained in law or accountancy I wouldn’t ask an engineer to build a 1,000 metre long concrete beam suspended at one end because I know it can’t be done, I have a physical perspective about it. With software, it’s never like that. We don’t have any underlying feel for whether something is even feasible."

This second gap is therefore related to the technical feasibility of IT systems. For example insufficient skills may be available to design and build the system, the required processing speed or capacity may not be commercially available or it may not be feasible to exhaustively test a safety critical system. In other words, the IT system as visualised by the business cannot be delivered to budget by methods, skills or technology available today.

The standard method of systematically addressing the Engineering Gap is the application of mature System Engineering disciplines, and through the re-use of proven subsystems and components. In spite of this, even package vendors sometimes get it wrong when they exceed the technical limitations of their product and end up at the bottom of the Engineering Gap.

The Engineering Gap often further stretches the cost differential caused by the Architecture Gap, because business visionaries and users can have no idea what a reasonable cost for the target IT system might be. Suppliers are often forced to assume a best case scenario for technical feasibility and then to dip under a reasonable price to win the business. Clients are lulled into a false sense of improved value for money, which often does not materialise because the supplier gets into financial difficulty and has to renegotiate or default.

Can we bridge the gaps?

The Architecture and Engineering Gaps are at the root of complex IT project failure. These gaps are caused by the inability of the business to communicate with Information Technology practitioners and vice-versa.

Any meaningful communication depends on people, in this case the Business and System Architects who are able to communicate across the gaps and ensure compliance with business vision and technical feasibility. In addition, it is necessary to fix the requirements elicitation process to ensure that it takes into consideration the architecture realities and other limitations of IT systems. Nobody in their right mind would expect a supersonic jet to also double up as a submersible vehicle! But an IT equivalent of that is often demanded by the procurer.

The protagonists must have a common language and realistic expectations. The emergence of consistent service orientated methods for all facets of architecture, combined with the use of architecture models based on visual modelling languages will help reduce the babel of incomprehension we have today.

Business and systems architects

The role of the Business Architect is to help bridge the architecture gap. They should have sufficient knowledge of the clients’ business environment to define and articulate a business architecture in response to the business vision. They should also be able to define the requirements for the application architecture and show how this will support the business architecture.

The Systems Architect on the other hand, is primarily responsible for helping to ensure technical feasibility, thereby bridging the engineering gap.

They are capable of defining the application and infrastructure architectures in response to stated requirements and are able to direct and ensure the integration of lower level designs.

A small handful of gifted individuals are able to act as both a Business and Systems Architect. They are invaluable in Chief Architect positions of complex IT projects. However, unless such an individual is available, the Business Architect should always defer to the Systems Architect on matters of technical feasibility, while the Systems Architect should consult with the Business Architect to ensure compliance with the business vision of the client.

A common approach

It is simply no longer feasible to capture and manage the underlying models of complex IT systems using word processors, diagramming tools, spreadsheets and presentation packages. Architects should make every effort to use industry standards, eg Universal Modelling Language (UML) for component modelling, Business Process Execution Language (BPEL) for processes and workflow etc. Tools are available to capture these models which hide the underlying complexity of the semantic standards. The tools help provide a visualisation of the target IT system, which allows users to participate effectively and articulate their requirements.

A common service-orientated approach should be adopted for the development of architecture whereby services are identified, specified and subsequently realised. This is an iterative approach of refinement. Architects should make maximum use of proven reference architectures and patterns for each of the facets of the architecture, as well as using proven packages, re-usable subsystems and components when making service realisation decisions. Architects would be well advised to track emerging standards such as Systems Modelling Language (SysML) and the emerging ontologies driven by work on the Semantic Web, which will enable an ever broader scope of the entire system architecture to be modelled using industry standards.


The right skills and a common language will make it possible to bridge the gaps and reduce the instances of IT project failure. The Standish Group estimated success rates in the US at around 34% in 2003, which represents a significant improvement on the 16% success rate recorded in their first survey in 1995. When placed in the context of the total IT spend, any improvement in UK performance will have tremendous direct financial benefits, while the indirect benefits for the economy as a whole will be even greater. The return on investment of any effort and money spent to improve the success rate must make this the best business case available today.

Biography – Pieter Lindeque FREng

Pieter is an IBM Distinguished Engineer and an active member of the IBM Academy of Technology. He has over two decades of experience in developing architecture and delivery of large, complex system integration programmes. This experience is now used to technically shape and assure the technical health of large and complex Systems Integration and Strategic Outsourcing programmes and bids.

Pieter is a Chartered Engineer,Master Certified IT Architect (The Open Group), a Fellow of the British Computer Society (FBCS), a Member of the Institution of Engineering and Technology (MIET) and was elected a Fellow of The Royal Academy of Engineering in July 2006. He is actively pursuing the development of methods, patterns and best practice to enable systematic asset re-use in the IT industry.

Download Article 240KB