A couple of years ago I did a series of blog posts featuring the views of experts on why large IT projects fail. I had 27 experts ranging from academics to IT services experts.
I enjoyed the series as did readers. Well it seems some were inspired.
Here are links to the series in full: 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, 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, part 26 Colin Beveridge and part 27 from Trevor Christie-Taylor
Inspired by the question, Mark Seneschall starting working on my challenge of summing up in a few hundred words why large IT projects fail? He ended up writing 100,000 words and has published a book. The anatomy of IT projects: why they’re hard, and why they fail, can be found here. And here is a website about it.
This is what Mark said about how a question posed in this blog inspired him to write a book.
“I suppose I’m something of an IT projects ‘nerd’ – I’m not an IT technician at all, my background is commercial, finance and control, but as I describe in the book I got sucked into these sorts of initiatives from the business side of things, and found them the most difficult, frustrating, horrendous – but also the most challenging, stimulating and ultimately rewarding – things I got to do in my entire career. From about 2002 onwards – at the same time as NPfIT was going on – I was working on some very big projects, and I knew how hard these were proving. While NPfIT was another order of magnitude bigger than what we were attempting, given my experience I felt I could understand and identify with some of the challenges it was struggling with. As a regular reader of Computer Weekly, when you posed the question in your blog, I thought I had something to contribute, and I started trying to draft my 200 words.
But at that time, although I’d begun work on the book, my focus had been more on the question ‘why are IT projects hard?’, principally because (as I describe in the introduction to the book) I’d been struggling to explain this to a company who I was then working with, who had kicked off a project to install a new end to end system to handle most of their activities, but had little concept of what this entailed. So my initial answer to the question ‘Why do these things fail?’ was ‘Because they are hard’. But then I thought about it some more. Being hard obviously raises the bar, but as long as you acknowledge that they’re hard, and respond accordingly to the difficulty, then you should still be able to succeed. For example, while it might be hard, say, for me to run a marathon in 3 hours, if I prepare properly for it, train hard, eat properly etc etc, ultimately I ought to be able to do it. So it isn’t actually the fact that these things are hard that causes them to fail (even though they are hard), it must be because the response is inadequate. This realisation, which arose from the thinking I did in response to the question you’d asked, and when combined with this other question of ‘why are these things hard’, led me particularly to come up with the ‘opposing forces’ concept I discuss in chapter 2 (ie that the complexity inherent in any project – IT or of any other type – needs to be met by a sufficient response in order for the complexity to be addressed and the project to succeed), prompted the discussion in chapter 6 around the factors that cause the response to be insufficient to address the complexity), and resulted in what is probably my most important conclusion – that the key to success in these sorts of initiatives is understanding as comprehensively as possible the complexity that you are likely to encounter when undertaking any such project before you start, and ensuring you are as well positioned as possible to address it. Perhaps this seems obvious – but on the other hand, as the discussion in Chapter 6 highlights, there are lots of reasons why organisations in practice very often do not do this – and the evidence from NPfIT and any number of other projects (and my own experience) supports this.
Ultimately, therefore, the question you posed really helped take my thinking to another level, and made the book a much more powerful and distinctive analysis than it might well otherwise have been…”