NHS IT project is dead, but why do large IT projects fail? Part 27

Following the news that the NHS National Project for IT was dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I was working on about why large IT projects are prone to fail.

<pbecause a p blog.<phere href="https://www.computerweekly.com/blogs/inside-outsourcing/2011/09/the-worlds-biggest-civilian-it-project-finally-looks-to-have-failed-but-it-is-no-surprise.html" the Brian Randell, part 2 Anthony Finkelstein, part 3 Yann L’Huillier, part 4 James Martin, part 5 Philip Virgo , part 6 Tony Collins, part 7 ILan Oshri, part 8, Robert Morgan part 9 Sam Kingston, part 10 Peter Brudenal, part 11 Mark Lewis,  part 12  John Worthy, part 13 Stuart Drew, part 14 Milan Gupta, part 15 from a reader known as Matt, part 16 Fotis Karonis, part 17 Fergus Cloughley, part 18  Steve Haines, part 19 David Holling, part 20  Bryan Cruickshank, part 21  Rob Lee, part 22 Tony Prestedge, part 23 BG Srinivas, part 24 Craig Beddis, part 25 Stuart Mitchenall and part 26 Colin Beveridge.

Part 27 today comes from Trevor Christie-Taylor who has had 20 Years in the industry. He is currently, chief architect of the Parliamentary Document Management System (PDMS) with the Australian Federal Government and associate of the National Centre for Information Systems Research.

He says, “1. One of the most important reasons for failure is the inherently predictive nature of the project structure. Because stakeholders are pathologically incapable of acknowledging uncertainty they construct a false certainty into the plans, which amounts to not much more than a guess plus contingency. Also management structure tends to value planning skills ahead of steering skills (steering is often left to a disconnected committee that steers by exception). As if this situation was not untenable the steering committee quite often constructs things in a way that it is difficult for the PM to communicate the ugly truth – effective steering is impossible the project falls apart in the face of reality.

2. Managers tend to see systems as whole entities that can be managed like a construction site, because they do not have the technical ability to see the details of the system. They cannot for example see whether a solution is a good design for the requirement or a bad one, and they cannot see the fluid nature of some aspects and the immovable nature of other aspects. They cannot identify a programmer who is a good problem solver but a hopeless designer or one who is a world class designer but a bad user interface person.

3. Finally I.T. program managers and planners often discount the emotional nature of some projects. Projects depend absolutely on the support of the users, the key stakeholders and senior management – nobody can be left out. Support means in the end that they must like the project and this means that the project must care about them (‘the law of reciprocal regard’). Sure, small insignificant projects or “pure IT” projects can succeed without this reciprocal regard but the big ones that involve thousands or tens of thousands of users (who just want to do their own jobs effectively) don’t stand a chance.”