Does any of this sound familiar?
'The system didn't do what we needed it to do'
'The organisation opposed what we were trying to do and the users refused to engage with the project'
'The supplier didn't understand our requirements'
'The users kept demanding more and more changes'
'It cost us five times as much as we planned, and delivered half of what we were looking for'
'We thought it would be like installing Microsoft Office - but it wasn't'
'The system didn't work the same way as our processes'
'The supplier said their system could do everything we needed - but it couldn't'
'We didn't realise what we were getting ourselves into'
'It was much more complicated than we'd expected and the consultants had led us to believe'
'The senior management lost interest as soon as it got difficult'
'The business handed over responsibility to the IT department and then just stood on the sidelines throwing rocks'
'How can IT projects possibly cost so much and take so long?'
About the Book
All the evidence suggests that IT projects that run into difficulties, cost more than originally envisaged, take longer than planned, or fail to deliver anything at all, are more the rule than the exception. What is less clear, and generally poorly understood, is why this should be.
In this book, Mark Seneschall draws on his own extensive experience as a participant in a large number of different IT projects, as well as a detailed case study of the NHS's National Programme for IT and analogies with engineering and construction projects, to explain why IT projects prove so often to be so difficult.
He argues that in most cases only a small part of this has anything to do with the IT itself - and that a wide range of other factors such as the ability of the organisation to identify clearly the problem or opportunity it wishes to address, or to make good choices about the solution and its suppliers, and to manage the various stakeholders who are affected by the project, are every bit as important, and often more challenging to resolve. In total, the book identifies over 25 different 'Sources of Complexity' that are likely to feature to a greater or lesser extent in most such projects, and which need to be addressed if the project is to succeed.
But the fact that they're hard does not fully explain the high incidence of project failure. The author argues that as long as the degree of difficulty faced by a project is met by an equivalent quality of response, then the project should still succeed. But in practice there is a widespread and consistent tendency of organisations of all types (public, private, and not-for-profit) to underestimate the complexities that their IT projects are likely to encounter. In particular most organisations still treat IT projects as largely technical, IT-centric initiatives, and as a result pay insufficient attention to many of the broader organisational implications and 'messy' choices to which such projects give rise. As a result, IT projects are frequently under-funded, under-resourced, and expected to take far less time than is reasonable. And then everyone gets surprised and angry when things go awry.
In light of this situation, Dr Seneschall offers some suggestions as to how best to negotiate these challenges, and maximise the chances of success. This begins with having the most comprehensive appreciation of the complexities the project is likely to encounter before the project commences.
This book, written by an IT project professional, offers a different, non-technical, pragmatic perspective on such undertakings, and as such provides essential reading for anyone involved in - or contemplating becoming involved in – any IT project
Contents
Introduction - the origins of the book
1. A diversion - Engineering projects are hard too... - examines some famous engineering projects to try to understand what caused them to be difficult
2. A framework for thinking about IT projects - draws on the engineering examples to develop a way of describing the different types of complexities that projects need to negotiate
3. An IT project case study: the National Programme for IT in the National Health Service -provides a detailed review of the project and its evolution
4. IT project sources of complexity - the things that make IT projects hard - seeks to 'deconstruct' the NHS IT project into all the different 'Sources of Complexity' that it encountered and sought to overcome (not always successfully)
5. What can possibly go wrong - another lens on the problems encountered by IT projects - provides an analysis of some of the common difficulties IT projects run into
6. Why they fail - the psychology of IT projects - discusses the widespread tendency to misunderstand the nature of IT projects and underestimate their complexity
7. Negotiating the complexities - provides guidance on how to overcome the complexities inherent in IT projects
8. Conclusion: Why IT projects are hard, and why they fail - they're hard because they are complex, multi-faceted and 'messy' undertakings; they fail because their nature is frequently misunderstood, and their complexity underestimated