Book Review: Troubled IT Projects
prevention and turnaround

John M Smith
IEE, 2001.

ISBN 0852961049 (boards)

Buy it from Amazon.com
Buy it from Amazon.co.uk

Other Reviews

It isn't very often that letters about a book disturb the calm pages of the CCEJ but that's just what happened when John Smith wrote an article about the subject of his book.

His first point of reference is the House of Commons Committee of Public Accounts' Report on the delivery of government IT projects. British readers will know that this is an immensely powerful body within Parliament, and one of the few that has the nerve to challenge both government and civil service over crucial matters such as accountability and waste of public money.

The Report itself is strong stuff:

"During the hearings on the NIRS2 system we were astonished to find that there did not appear to be a shared understanding between the Contributions Agency and Andersen Consulting of what was meant by 'delivery of Release 1c'. .. They also did not appear to have a shared understanding of each other's responsibilities under the PFI contract."

"[T]he Committee is very concerned at the number of Government IT projects that are not delivered on time or at all, are completed over budget, and either fail to match specifications or require significant changes before they are satisfactory."

"[T]he Committee is very concerned at the number of Government IT projects that are not delivered on time or at all, are completed over budget, and either fail to match specifications or require significant changes before they are satisfactory."

and as if that were not enough:

"16. The Committee and its predecessors, as well as the Comptroller and Auditor General, have reported on problems with Government IT projects on more than 25 occasions during the 1990s. ..."

"17. ... Of particular concern is that:

• fourteen of these reports have been published in the lifetime of this Committee;
• problems continue to occur in areas where the Committee has made recommendations in the past; and,
• similar problems have occurred under successive new methods of procurement, including most recently, Private Finance Initiative deals."

In other words, the situation has been dreadful, is not improving, and looks to be becoming more complicated.

Smith's take on this is that there are not very many 'Root causes' of troubled projects: he comes up with a list of just 40 of them. This is a number quite close to one of his other favourites, Georges Polti's Thirty-Six Dramatic Situations (first published 1921). Smith says he 'was unable to find more than 40 generic root causes'. I'm reminded of work done by Neil Maiden and his colleagues searching for Exception Classes so they could generate and test candidate scenarios (in naval warfare). Smith's 40 causes fall into six groups - project conception, project initiation, system design, development, implementation, and finally operations (through to disposal). They'd make a lovely use case model of the system development process itself, which could act as a project manager's/system engineer's assistant to guide intelligent planning, preparation, and project engineering, but that's another story.

For instance, during implementation, root cause 34 identifies 'Buyer failure to manage the change implicit in the project (people, processes, technology)'. This names something rarely considered, the politics and energy needed to bring about a transition in an organisation. Checkland may have written about soft systems over 30 years ago, but the problems remain current: you aren't just building a system, you are changing an organisation, and what is more, you are designing a process for bring about that change. Often, especially when no-one has considered it, that means a very bad process.

Smith has drawn attention to a whole heap of practical wisdom, most of it won through a huge amount of other people's bitter experience. Good system engineering and project management practice is often said to be common sense, and so it ought to be: but as the saying goes, it ain't that common. Enormous amounts of public money continued to be wasted each year on troubled projects; private ventures too go wrong quite often, though of course they do not so readily become public knowledge.

The obvious question to ask about a book that discusses things that go wrong is, what can we do about the problems, and how can we do things better? With the picture of HMS Nottingham holed on the rocks off Australia firmly in our minds, the right if topsy-turvy answer to 'how can I get to Sydney safely?' is 'by not starting from here'. Smith subtitles his book "prevention and turnaround", and we may suspect that the former is more often going to be effective than the latter. Happily, Part 2 of Smith's book offers guidance on detecting root causes early, and on reshaping and relaunching a troubled project.

This book should be of immediate interest to all system engineers and project managers, perhaps especially if they are involved in large IT ventures such as PFI's for a government. Students struggling with essays on project engineering and management may also find it rather useful.

I mentioned that Smith stirred up letters to the CCEJ editor; there were 2 in the October 2002 issue, and they were both interesting.

Peter Duschinsky pointed out two more perils to projects: a review process that lacked the power to stop the project if it was failing (i.e. to behave as a 'gate'); and a similar lack of power among project managers. Either way, people who can see that something is wrong need to be able to act: and they often can't.

Martyn Thomas argues from a totally different perspective that many of Smith's root causes stem from poor specification, which he says could be improved with formal specification languages such as Z, VDM, or B. Thomas optimistically concludes that "When software development is widely recognised as a rigorous engineering discipline, troubled IT projects will be a thing of the past." Smith replies that he isn't sure, as some projects don't have time "to prepare formal specifications and go through the 'waterfall' process". From this one can guess that Smith presumes that projects don't even have time (or knowledge?) of the traditional requirements, specifications, design, test, operations sequence, let alone clever stuff with iterative and co-operative development, and that they wouldn't know a VDM specification if it bit them on the nose.

But in any case, it seems safe to conclude, with Thomas, that "Until then, John [Smith]'s book should be open on every software manager's desk". To which I might add: and its ideas should be open in every system engineer's mind; for the problems that Smith addresses are limited neither to project management nor to software engineering.

Letters from Peter Duschinsky and Martyn Thomas, IEE Computing & Control Engineering Journal, October 2002, 13, 5, page 263

House of Commons Committee of Public Accounts Report on the delivery of government IT projects, The Stationery Office, 24 November 1999

© Ian Alexander 2002