top of page

About the Author

Mark Seneschall has 30 years commercial experience, mostly in a large British multinational, working in a number of different functional areas and geographies. He spent a large part of his career heavily involved - as process change lead, project manager, and ultimately programme director - in a diverse array of major transformation and 'IT-enabled business change' projects, some of which were global undertakings with multi-million pound budgets. More recently he has worked as a management consultant providing advice and support on IT and change projects. He is a qualified accountant, and has a Ph.D and a football blue from Cambridge University. He is married with two daughters and lives in Buckinghamshire.

Why I wrote this book*

It was in a meeting with the management team of a business which I had been asked to help out with an IT project that was proving somewhat problematic. Almost the first thing I said during this meeting was 'These things are hard'. To which the management team smiled and nodded. Several months later, at another meeting with the leadership team, and having spent the intervening period wrestling - with mixed results - with assembling reference data in the format and to the full extent required by the new system, obtaining final business sign-off on requirements (and then specifying a bunch of changes), defining, developing and agreeing a sensible list of test scenarios, managing resistance - and requests for more changes - from some of the users and some of the management team, maintaining reasonably civil relationships with the supplier against a backdrop of growing mutual frustration, and more...(did I mention reference data?), and with the project continuing to prove problematic, I reminded them of what I had said. And again they smiled, although perhaps rather more ruefully than the first time round. Musing subsequently on this, I wondered whether when I said 'These things are hard' the first time round they really had very much appreciation of what this meant at all. In a way, I might just as well have been speaking Ancient Greek (not that I speak Ancient Greek). On reflection, in many respects, 'These things are hard' is perhaps not a particularly useful thing to say. 'Hard' (as in difficult) is a relative term, of course. And depends on the context. Lots of things are hard. Long division is hard. Running a marathon is hard. Childbirth is hard (so I’m told). But the nature of ‘hard’ is different in each case. If you’ve been through any of them, then you know what the ‘hard’ in question really means. But if you haven’t, you don’t. So while I'm certain that my comment was accurate and justified – these things really are hard - it wasn't necessarily very helpful.

 

Following from this, the question it raised for me (and raises) is how to provide a sense of this to those embarking or embarked upon IT projects but lacking in a deep appreciation of them. I suspect that this group is in fact the norm rather than the exception – after all, there is widespread evidence to suggest that a significant proportion of such projects struggle to some degree. But I wasn't able to find a simple way of describing this (no-one who hasn’t had to do it really believes that assembling reference data – in the required format – can possibly be all that difficult; tedious, yes, but difficult, no!). Neither did I have much success in finding a good analogy that both worked for me and also resonated powerfully with people. There are obvious parallels with engineering and construction projects, of course, and these can be very instructive – not least because of the differences as well as the similarities. But the differences mean that they only provide partial analogies at best.

 

Given this widespread lack of appreciation of what’s really entailed in the successful delivery of even a relatively straightforward IT project, and the challenge in articulating the reasons why such projects should be as difficult as they seem to be, the best solution I could think of was to try and write it down. Hence this book – so that next time I see my audience’s eyes start to glaze over, and I see them thinking ‘Hard?...whadaya mean these things are hard?...in my job I do lots of things that are hard...I don't see anything here that's all that difficult' (or words to that effect), I can at least have something to hand that I can give them and say ‘you might want to read this’...

 

* extracted from the Introduction to The anatomy of IT projects: why they're hard and why they fail - A guide to the complexities and how to negotiate them by Mark Seneschall

bottom of page