(This post contains affiliate hyperlinks. Please read my full disclosure.
It’s a strange experience to read a book on project management that doesn’t use the language of business analysis or project management. Phil Simon’s book Why New Systems Fail – Theory and Practice Collide is a study of IT projects that fail from a consultant’s point of view.
Simon has a lot of experience in implementing large-scale systems. It is evident from anonymised case studies that Simon has seen success and failure, and has been involved in correcting some huge mistakes.
It is difficult to see who Why New Systems Failed is intended for. Simon states that the book has no intended audience. It is high enough for executives in the C-suite to understand what they are doing wrong, with some detailed chapters. It informs project managers about the pitfalls and how to avoid them. It is primarily focused on the implementation of enterprise resource planning (ERP), and HR systems. It would have been nice if there were examples that went beyond the HR arena. I also think the audience may be limited by the lack of these examples.
The book is divided into five sections. The first section, titled “Deciding to take a leap”, examines why organisations still use legacy systems and the decision-making processes that are required to implement large-scale systems.
The second part focuses on system selection. It demonstrates that software salespeople don’t always know as much about their systems as they should. The second part discusses the need for business processes to be reviewed, but not much on how to do this. This section also deals with selecting consultants. It is one of the longest chapters in the book. Simon could make this a topic for a second book. He writes:
Organizations often choose only those consultancies that seem most flexible and obedient. This is a huge mistake. This is a huge mistake.
Part Three covers system implementation from setup through delivery. It touches on testing. It describes unit testing as “End users test specific scenarios, and not entire business processes, from soup to nuts.” This doesn’t seem right to me.
Part Four focuses on life after the system is live. This is something that not many project management books cover. We’ve moved on to the next project once the project is over. Poor end-users are those who remain stuck with an ERP system that doesn’t work. Simon discusses the need to have an ongoing plan for system maintenance. This involves maintaining good working relationships with the vendor and is often overlooked until it is too late.
The last part is the section on maxims, i.e. If you haven’t yet learned anything, let me remind your of my messages. Simon emphasizes the importance of audits (and I too love them). Chapter 20 discusses how to build a margin for error without using the language that would be expected in project management books. This is again to highlight the fact that the audience are not project managers. This section also discusses finding the right people, and bravely getting rid of the ones that are not.
Simon’s conclusion summarizes the key messages of the book as follows:
Before you begin, be aware of what you are getting yourself into
Don’t reinvent the engine
Keep it simple
Keep it simple
Know your organization
Don’t believe any vendor when they promise you a grain salt
Get it