The NHS IT project is dead, but why do large IT projects so often fail? Part 2.

The £11bn NHS IT project looks has been scrapped.  

By coincidence I have been doing the rounds recently asking industry experts why they think large IT projects fail. This is for a feature I am putting together, which will appear on Computer Weekly soon. 

Now that it looks like the NHS National Project for IT is dead and buried it seems apt that I start to publish the views of some of the experts on why large IT projects fail.

I started yesterday with the comments made by Brian Randell. He is a professor of at the School of Computing Science at Newcastle University. 

He was a member of the group of academics who became concerned about the UK National Health Service’s National Programme for Information Technology (NPfIT). He edited the dossier documenting the concerns. See it here.

Today features Anthony Finkelstein. He is professor of software systems engineering at University College London (UCL) and dean of UCL Engineering. Active in industry consulting, he is a fellow of the Institution of Engineering and Technology (IET) and the British Computer Society (BCS).

So why do large IT projects fail?

Finkelstein says: “The Standish Group in its methodologically dubious but nonetheless useful, CHAOS reports cites reasons such as: inadequate user involvement, unclear business objectives, failure to control scope, poor architecture, requirements volatility, unsystematic development process, unreliable estimates. None of these would come as a surprise to any IT professional. The more interesting challenge is why therefore do we appear to be bound to repeat these same mistakes? I would argue that the problems are more fundamental and not essentially technical – they lie in governance. That is, in the structure of relations and incentives that bind together the business and IT functions of an organisation. An organisation with a flawed governance structure cannot articulate its requirements, charter a project, identify appropriately skilled staff, manage the concomitant change process, determine if the project has been successful or even deal with the consequences of failure. Governance is becoming more complex as we increasingly have organisations with federated and outsourced business structures. We will neither understand project failure nor be able to address the causes until we have addressed governance.”

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Many IT projects fail due to an inability to properly assess the quality of work throughout a project. This can be down to issues such as a lack of ownership of quality control or inter-team communication. However if the project is broken into smaller and measureable phases, it can be more easily managed and allows responsibility to be given to specific team members at given stages. Accompanied by the right intelligent automation, team members can concentrate their effort on the high value-add of the project, regularly tracking and monitoring performance while the process itself is automated. This means that IT projects become more engaging; IT can invest more time with the business, both understanding and managing stakeholder expectations, meaning that realistic SLAs are more likely to be set and met. And projects are much less likely to spiral out of control with continued scope creep, manual error and grinding hours spent on individual task management.

Craig Beddis, Regional SVP at UC4 Software

Another problem (related to governance) is the failure to understand content v context. I.T. Projects are managed as if they were a thing, not an organic and continuously changing show. There are two distinct types of control needed the internal control of the system under change (Architect's Job) and the external control of the budget stakeholders and so on. It is the same model as movie making (Director and Producer) The BCS and the Royal College of Engineers got it absolutely right - there need to be three named responsible persons, Business Stakeholder, PM and Architect. And yet the major project management methodologies only mention two of them.