Why do large government IT projects go wrong?
The poor taxpayer is faced on a regular basis with newspaper stories telling us how much of our money is being wasted on failed IT projects by the government. If you read the IT press the story is the same, it is just the coverage that increases. Just what is going on here?From the NHS e-records system to the Defence Information Infrastructure programme, the value delivered is dreadful, estimated to have cost taxpayers £26bn for just the top ten failures under the last government alone.
The traditional means of ensuring best value for money for the taxpayer is the tender. This process involves offering the work to the market, and allowing organisations that meet a predefined set of criteria, covering size, maturity and capability amongst other conditions, to bid for the work. Let’s examine the realities of this process and the consequences of applying it to larger projects.
In order to put the work out to tender it must be adequately described, with a specification document that fully describes what is required of the ultimate solution. This document will be prepared by the organisation requiring the system, and will usually involve many users across all departments.
This of course raises some very important questions:
If an organisation is asking someone else to write an IT system for it, is that organisation really capable of actually specifying the requirements of the system itself? Clearly the domain knowledge carried within the consumer organisation is of massive importance, but will that organisation really have the skills to write an optimum specification for an IT system that does not currently exist, when IT is not it’s core competency?
The various departments being asked for their input will all have their own budgets. They will be well aware that the budget for the new system will not be borne by them, but that changes required to it later most probably will be. Can this very process lead to a large amount of over specification, where all manner of reports and ancillary functionality is ordered that will never show a return on investment? Remember, IT systems, like most other systems, suffer from the 80/20 rule, where 80% of the benefit is delivered by 20% of the software.
So, the client organisation has written a large specification document, the phone book if you will, and suppliers are bidding for the chance to write the system.
As the supplier is being paid to deliver to the specification, the best system that can ever be delivered is that described by the specification.
As the size of the system increases two further effects will become significant:
- The probability of their being an error in the actual specification itself will increase. If this error is in a core part of the design it may well impact every other part of the system, requiring significant rework and change requests.
- The time to write the system will increase. The longer the system takes to write, the more likely it is that the underlying business, and hence it’s requirements, will change.
Further both of these adverse effects can be compounded by the reduced visibility during the development stage where the development team goes dark. As nothing is being delivered no one is actually aware of the mismatch between current requirements and the software that will in the future attempt to meet those requirements.
It would appear that the very system designed to ensure best value for money for the taxpayer, the competitive tender, may in fact lead to overspecified systems, that are likely to never reach their full potential and carry a huge risk of failure that scales very badly with the size of the system. As we haven’t even factored in the overheads of applying for tenders yet, borne by each supplier so factored in to bids multiple times, it is not a very pretty picture overall is it?
So, is there a better way to deliver IT systems, whilst ensuring value for money for the taxpayer?
We will address some possibilities in later posts.