Following the unsurprising news that the NHS National Project for IT has been dropped I thought it apt to blog 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 soon, asks the question: Why do large IT projects fail?
So far I have blogged the answers to this question from two computer science academics.
I started with the comments made by Brian Randell.
Randell 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.
Then part two came from 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).
Today, in part three, it's the view of Yann L'Huillier.
L'Huillier is group CIO at financial services giant Compagnie Financiere Tradition. Before his current role he was CIO at trading exchange Turquoise where, in eight months, he delivered the complete set of IT solutions, procedures, processes for the exchange to go live in August 2008. He was CIO at the Boston Stock Exchange (2003-2007) where he designed and launched the Boston Equities Exchange trading platform. He spent seven years at the Toronto Stock Exchange where he developed the new Equity Trading Systems.
He says: "Big projects can't be completed on budget or on time. But it's not only IT projects, usually some of the big architecture, engineering projects fail. You will find some common reasons to all; the first one is that even though most of the budgets are usually well done from the start, in order to get them approved, they must be scaled down, contingencies removed and to a level where they will receive the blessing of the deciders/payers. Once they are approved there is nothing left for the unexpected events (Murphy's law for example). The second reason is that between the time the decision is taken, the project starts and is completed, the situation will change several times. The economics, regulatory [environment], and competition don't freeze at the start and therefore big projects need a wider scope than the original one. One should plan for unknown changes and have enough buffer in financing and scheduling to account for anything that will go wrong. Lastly, when projects are delayed, the wrong solutions are often used, such as increasing the staffing instead of de-scoping or phasing the deployment. 'Design is a democracy but implementation is a dictatorship'".