Why are IT projects so hard? That’s a question worth considering in some depth.
I once had a conversation with the management team of a medium-sized business that had embarked on a project to replace its existing manual and spreadsheet-based processes with a new system.
This was proving problematic, and they asked if I could assist. The first thing I said to them was, “These things are hard”. They nodded and smiled politely. But as events unfolded, and we arm-wrestled the project to some sort of conclusion, it struck me that they still did not really have any genuine appreciation of why the project should be so difficult – and that equally I didn’t have a simple explanation available that I could give them, despite 20 years’ experience of IT projects.
While I was thinking about this, the government announced the dismantling of the NHS National Programme for IT. Computer Weekly subsequently posed the question to its readers: “The NHS IT project is dead, but why do large IT projects so often fail?” and invited comments.
I attempted to compose my own answer to this question – along the lines of “because they’re hard”. But this brought me back to the first question -why are they hard? - and also raised another one: there are lots of things that are hard, but they don’t necessarily fail. So the degree of difficulty might be part of the answer, but there must also be something else going on.
Mark Seneschall is the author of The anatomy of IT projects – why they’re hard, and why they fail.
My attempt to answer these questions started by looking at some well-known engineering projects, and trying to understand what it was about them that made them hard. What emerged was that these are not just about the engineering - all sorts of other factors come into play.
You have to consider three things: the situational factors, which relate to the particular context in which the project takes place; inherent factors, which are likely to be manifest to some degree in any project; and events - things that happen in the course of a project which affect it. What’s also apparent is that in order to be successful, the project has to achieve at least a “passing grade” in the way it addresses all of the different factors – otherwise it will fail.
If you apply this framework to the aforementioned NHS IT project, and attempt to deconstruct it into all the different factors or sources of complexity, you can identify some of the problems it faced – such as the size, structure and culture of the NHS; selecting the solution and the suppliers; the organisational change aspects; engagement with users and other stakeholders; governance and sponsorship and so on – which of course are the very same issues that are encountered by many and probably most IT projects.
This illustrates first, that IT projects are not just about IT; and second, that for many of these different aspects, there is no definitive right answer as to how best to address them – instead, it’s a matter of choosing between a range of alternatives, all of which have relative advantages and disadvantages, and different consequences and implications.
Read more on IT project management
Plotting a course through the maze of complexity therefore relies on skill and judgement – and given that the projects are not just about IT, the skill and judgement required extends well beyond just that related to IT.
If this explains why IT projects are hard, it still doesn’t answer the question why they so frequently fail. As long as the complexity encountered in any project is met by an appropriate response, where the requisite expertise and experience is employed and good choices and judgements are made, then the project should still succeed.
But of course, it isn’t, and they aren’t - which raises the question why this should be, especially given all the evidence about the failure rate of such undertakings. The short answer is because of a tendency on the part of organisations of all shapes and sizes to underestimate or to ignore much of the complexity that the project is likely to encounter – in part because they conceive of them as largely technical IT-centric undertakings, rather than the multi-faceted initiatives they really are.
So how can organisations best overcome this situation and maximise their chances of success? You need to begin by ensuring they understand as much as possible about the complexity they are likely to encounter before they embark on the project – time spent in reconnaissance is seldom wasted.
Mark Seneschall is the author of The anatomy of IT projects – why they’re hard, and why they fail. He wrote the book after attempting to write a 200-word response to Computer Weekly’s request for comments about why IT projects fail, and found he needed 100,000 words to do so instead.