Oct 7 2005, public sector IT projects and the “blame game”

There’s an interesting piece in Prospect (October 2005) by Michael Cross on Public Sector IT Failures (available online at the time of writing – click here). The article provides a useful review, looking at how the UK compares with other countries in terms of the relative number of IT-related projects that succeed or fail. There are clear national differences in the approaches used for large scale projects – with the Netherlands for example breaking them into much smaller component parts to control risk and open up project delivery to smaller players in the marketplace.

One key point is I think often missed when failing IT projects are criticised. Major IT projects are fundamentally major business change projects: and often it is the change programme itself at the root of the problems that arise. The IT systems are usually just the most visible evidence of the failures or problems associated with such major change programmes. To understand the real root causes of high profile project failures requires a greater analysis and understanding of the way in which high level government policy is interpreted and executed upon as it passes down the chain of command. The way in which for example manifesto policy aspirations are than encoded into projects and eventually into IT requirements.  All too often inquiries into project failures look at only one component aspect of the problem – the IT systems – rather than the overall project of which those IT systems formed a part. That is why I suspect we see the same problems repeating themselves time and time again.

Looking back at my own time in public service, and the way it continues to operate now, the public sector risk/reward model itself also requires review to help provide an environment better suited to the delivery of major change programmes. There should also be a review of the way in which IT projects still seem to be built on the out-dated and unsuccessful ‘built to function, built to last’ principle: when best practice has moved on to the ‘built to adapt, built to change’ model. Likewise, the old monolithic thinking around waterfall projects should also be pensioned off once and for all: we have far better ways of delivering successful projects represented by the component approach (connected systems and service oriented architectures) and more flexible project methodologies that deliver better results.

It’s important that we learn and apply these lessons now. Look ahead for example at the type of flexibility we will require in the administration of public sector services in the future. We know that the current idea of a fixed retirement age and associated pensions regime is under enormous pressure. It seems likely that the model will change to one where retirement will happen as a gradual process and over a longer time period than at present. Those of my own generation may well find themselves only semi-retiring at first, maybe drawing part-pensions but still also partly working. The demands this will place on our currently functionally silod systems of taxation, benefits and pensions will be immense if we do not both reform the business processes and the IT systems to support the flexibility that is likely to be required.

In order to enable technology and business needs to work more closely together to deliver projects that meet requirements, it is essential that we find some way of communicating the true value of technology to our business decision-makers and policy-makers. We are increasingly reliant at every level of society on new technological innovations in both software and hardware – yet the number of people who understand either the technology or, more importantly, how we can use and manage it to real advantage, to re-think and improve the way we learn, work and live, remains worryingly small.

Unless we can find a way of better articulating the way in which technology and business can interact to truly beneficial effect, we seem likely to continue to see failed IT projects and associated public service change programmes that frustrate both those who provide them and those of us who use them.