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.
Because I have had such a good response I am keeping the debate going in the blog.
Here are the posts already published: Part 1 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.
If I get comments from readers I will try and include them so please send me your views on: Why do large IT projects fail?
Today in part 19, I feature the comments of a reader, David Holling. He provided his views as a retrospective comment after reading the first 9 posts.
He says: “Certainly decomposition is a critical part of the approach – but in order to successfully decompose, one has to have a detailed description of the constituent components, their interrelationships, (not purely process mapping or functional breakdowns…), and showing many “views”, all done in a technology / implementation agnostic manner whilst wrestling with the subjective niceties of unspoken assumptions and lack of common meanings.
1 – involves a lot of work with business stakeholders, who cannot necessarily commit time or are prepared / able to make operational and policy decisions before seeing a “system.”
2 – Requires analytical skills not possessed by many.
3 – Has to be done in a manner to explicitly build in flexibility and change resilience. Is it a coincidence that the most successful parts of the NHS project can be viewed as pure technology implementations requiring little business input (e.g. the spine)?”