Title: Buying Information Systems: Selecting, Implementing and Assessing Off-The-Shelf Systems
Author: David James
Reviewer: Stephen Jones
How should you approach the purchase of packaged business information systems? Most managers will only be involved in this once or twice in their career.
David James is a Chartered Engineer, a Fellow of the Institution of Electrical Engineers and has a doctorate in business research and applies the perspective of his engineering background in large manufacturing systems integration to supply a framework for the process of Selecting, Implementing and Assessing Off-The-Shelf Systems.
Buying Information Systems reviews the basics and illustrates the key points with illustrative examples.
I had mixed feelings about the book. If you have never undertaken such a project before then this is probably not enough guidance, and if you have done it successfully then you may find much of the book too high level.
It will certainly help you to structure your thoughts, and to ensure you do not miss out important steps. I found the page set up and font did not endear me to the book initially, fewer words per page even at a higher cost was my thought.
However, there are useful checklists and diagrams, and case studies/anecdotes that break up the text and the writing is clear and not too heavy despite the subject matter, so I got through it faster than expected. My second reservation is that there is so much good advice available for free on the internet these days, much of it not in this book. To be fair, David James does point out further sources of guidance. A glossary aids with the jargon.
The book’s title order is perhaps inappropriate. It is definitely more about selection and implementation than about buying, that is to say the project management perspective is evident.
This is not necessarily a bad thing. The book answers some fundamental questions: where to find advice; who should be involved; how to manage the purchase; how to decide what you need; which package or supplier to choose; how to manage the implementation, and how to evaluate if the system is successful.
Some of the important topics are covered at a high level, but I feel those who need a book like this probably also need more guidance.
A common mistake I find is that the wrong people often make key decisions, and for the wrong reason. James correctly stresses the importance of stakeholders.
Buying business systems software is not something to do lightly, yet it is often left to IT. The negotiation of prices, warranties, and agreeing contractual terms, requires expert negotiation by purchasing professionals and legal input, and project evaluation techniques from finance such as discounted cash flow.
These are all alluded to but there is not much detail, it is assumed the relevant professional will know these things. In these days of Sarbanes-Oxley (not mentioned despite being a 2004 book) and new accounting standards, these factors will play an increasingly important part in the process.
More important is to have clear strategic objectives. Such high ticket items command professional salesmen. The evidence is clear time and again that it is the best salesman that wins the sale, not the best system. The relationship with the salesman and emotional factors often outweigh more concrete facts.
Too often the end users never get near the software, indeed most sales people will try to ensure this. If you don’t want to be one of the 50% of IT projects that never complete, then get your end users to run some of your own data through the software for typical business scenarios.
Business system vendors don’t like that, they will answer ITT questions with pat answers, will demo all the sweet spots and may even be persuaded to do a proof of concept, but its not the same. Pay a small percentage of your budget say 5-10% up front for a proper run through.
That way you will avoid big mistakes and cost overruns, you will see what really comes out of the box and what has to be developed, just how integrated the system is, how the system responds, what the learning curves and data preparation loads will be, and get a feel for documentation, stability, helpdesk support, etc.
To get back to the book, the content is clearly presented and authoritative, but perhaps it is too broad a scope for its size. There is some common sense advice here and I would have preferred to see the book focus on vendor selection, product assessment and the negotiation phase which is a big enough range of subjects. There is much more literature on project implementation methodology – vendors have given a lot of thought about how to help you to implement their software – on vendor selection, caveat emptor.
The problem with any book is that the author has to guess the questions you want him to address within the space available. I came away with the view that David James knows his stuff and would be a great guy to have around on a project – but I wish he had gone just a little further with some sections of this book. Ii summary I think it is a better student text than a practitioner’s working guide, though both will find it useful.