Following the news that the NHS National Project for IT has been dropped I have been posting some of the views I have recently had provided to me for an unrelated feature I am working on.
The feature, which will appear in two parts on Computerweekly.com , asks the question: Why do large IT projects fail? Here is the first part.
Here are the other parts 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 and part 12 John Worthy
I am looking for more comments. If you want to contribute please send you answer to the question: why do large IT projects fail? It must be under 200 words. Please send a short biog and a picture. I can’t publish them all but I will consider them all.
Part 13 today is from Stuart Drew, executive vice president at HCL Technologies Europe.
Before joining HCL, Stuart Drew was with Deloitte as senior director – financial services. He worked on the Congestion Charge project while at Deloitte. He joined Deloitte after seven years at Prudential, where he was a member of the retail board.
He says: “Every year millions of pounds are spent on high-profile IT projects, many of which involve experienced, big-name companies with access to a great pool of resources. But with this in mind, why do so many of them fail? In my view, there are three principle reasons why major IT projects most commonly and consistently fail.
Firstly, I believe that large projects do not ‘go’ wrong – they ‘start’ wrong. I always tell project leaders to imagine that they are in the dock under cross-examination with the brief asking: ‘When was the first time you thought this was off track?’ Without exception, they always admit that the source of the problem was to be found long before they admitted it ‘went wrong’. Contributing factors to this can be a fear of failure, a lack of deep enquiry on a regular basis, and a lack of rigour around change control.
The second issue is one of ineffective governance. Much lip service is paid to project governance, yet there are still too many people who do not understand what it is and how it should work. Shared accountabilities are dangerous, stakeholders are not all identified and handshakes between component contributors are too frequently unclear and undocumented.
Finally, failure to keep the end goal in mind can play a significant role. Project creep is too common and must be resisted at all costs, notwithstanding project ambitions also change. Overall, it’s important that the single (it must be one) project manager must remain brutal in the rigour of their execution, and must always keep top of mind the ultimate objective.”