Book review: Why new systems fail

This blog is reader-supported. When you purchase something through an affiliate link on this site, I may earn some coffee money. Thanks! Learn more.

Read our review guidelines.

It’s an odd experience, reading a book about project management that uses none of the language of project management or business analysis. Phil Simon’s book, Why New Systems Fail: Theory and Practice Collide, is a study of IT project failure from a consultant’s perspective.

Simon has plenty of experience of implementing large scale systems, and it is clear from the anonymised  case studies that he has seen both success and failure in the work he has done, and been involved in putting some monumental mistakes right.

It’s hard to see who Why New Systems Fail is aimed at. Simon says the book “has no one intended audience.” It’s high-level enough for C-suite executives to work out what they are doing wrong, but there are some detailed chapters. It tells project managers about the pitfalls of large scale package software implementation, without telling them much about how to get it right. And it is highly focused on implementing enterprise resource planning (ERP) and HR systems. It would have been nice to see some examples outside of the HR arena and I think the absence of these may also limit the audience.

The book is split into five parts. The first section is called ‘Deciding to take the plunge’ and looks at why organisations maintain legacy systems and the decision processes required to get to the point where a large scale system implementation is the answer.

The second part talks about system selection, hammering home the message that software salespeople are never as clued up on what their systems do as you would like. It discusses the need to review business processes, but without paying a lot of attention to how you would go about doing this. This part also covers selecting consultants, and this is a very interesting section and one of the largest chapters in the book. If Simon does a second book, he could consider this as a topic in its own right. He writes:

All too often, organizations select only the consultancies that appear to be the most malleable and obedient. This is an enormous mistake. Companies should certainly not choose partners that are rigid, irritable, and outright rude… Organizations should hire consultants who insist on doing their fundamental job throughout the duration of the project: being the product experts.

Part Three covers the system implementation from set-up through to delivery. It touches on testing, describing unit testing as “End-users test specific scenarios, not entire business processes from soup to nuts.” In my experience, unit testing is something done by the programmers, before the system is handed over to end-users to do their UAT, so that didn’t read quite right to me.

Part Four looks at life once the system is live, something that many project management books don’t cover. After all, once the project is closed, we’ve moved on to something else. It’s those poor end-users who get stuck with an ERP system that doesn’t work. Simon covers the need for an ongoing plan for operational system maintenance, which involves keeping good working relationships going with the vendor, and is something often forgotten until it is too late.

The final part is the section of maxims, i.e. if you haven’t learned anything yet, let me remind you of my messages. Simon stresses the value of audits (and I’m a big fan of these too). Chapter 20 talks about building a margin of error without using the language of tolerance, risk or contingency that you’d expect to see in most project management books – again, highlighting the fact that the audience is not ‘professional’ project managers. This section also covers finding the right people and – bravely – getting rid of the wrong people.

Simon’s conclusion summarises the book’s key messages as follows:

  • Know what you are getting into before you start
  • Don’t reinvent the wheel
  • Keep it simple
  • Keep it small
  • Know your organisation
  • Take vendor promises with a grain of salt
  • Get it in writing
  • Find trusted consultants
  • Plan for delays
  • Watch out for data conversion
  • Allow enough time for testing
  • Expand cautiously
  • Don’t rely on one or two internal employees.

This last point is illustrated earlier in the book with a hilarious case study of the HR employee who awarded himself pay rises, confident in the knowledge that he couldn’t be fired as he was the only one who knew how certain systems worked.

There is plenty of good stuff here, but Why New Systems Fail is self-published, and it shows. Not in the publication quality – AuthorHouse has turned out a pretty good looking book with an attractive cover and decent paper. But there are some things about it that a professional editor would have put right. A lot of the footnotes are from Wikipedia, and I can’t tell you how much it annoyed me to have definitions of common words followed by (Source: Wikipedia). A glossary would have been so much better.

It’s a good, entry-level book for someone contemplating, or working on, a major ERP implementation. But there are books who take the topics here and do them better, which readers can graduate to once Why Systems Fail has got them interested enough in doing a good job. One that sprang to mind as I was reading the section on choosing the software is Guide to Software Package Evaluation and Selection: The R2ISC Method, by Nathan Hollander, which is not half as entertaining or easy to read as Simon’s book, but it’s an excellent starting point for anyone about to embark on buying and implementing an IT system.