Make vs. Buy Decision and the Art of Consulting

Chenault Systems is often called in by organizations to “support” a particular software system bought off-the-shelf. Many times, after objective examination, we determine the system, although a good tool is not right for the process.

We are independent from all software products and vendors. While our staff members may be certified in certain software products, we are not aligned with anyone. Independence and lack of alignment allow us to be objective. This objectivity is what makes Chenault Systems unique from most other firms. This is true consulting.

Physicians within the medical profession have the same philosophy. Doctors are completely independent (or should be) of drug companies and medical equipment companies, regardless of specialization. Management consultants are really business doctors; and, as a management consulting firm, Chenault Systems specializes in information technology. Our clients rely on our independence to cure their system problems in an objective manner, much like how a patient relies on the physician.

Over the years, we have encountered many situations where management was persuaded by skilled sales people to purchase a software package to streamline and automate a process. Typically, the in-house information technology group and a few high level managers evaluated the product, comparing the features and benefits to other systems, and no one consulted the end users, the true experts of the process. The typical result: A round peg is forced into a square hole, forcing people to change the process to match the product instead of the other way around – or in other words, failure.

This scenario occurs for everything from small asset management systems, costing a few thousand dollars, to the very large ERP systems, costing millions of dollars. In many cases, contracting a consulting firm to custom build and support a system would have been less expensive than purchasing from a software vendor. Less expensive custom software is possible because today’s products allow relatively rapid application development, which dramatically reduces development cost, and at the same time allows the client to maintain process control and ownership.

Book Review: Systems Survival Guide for the "Systemically - Challenged" Executive - A Step-by-Step Handbook of Simple Instructions for Selecting, Purchasing and Implementing a Software System in your Organization

By Michele M. Pavlyak

(Ruby Moon Press, $19.95)

By Tom Chenault

This is the first book of its kind. Systems Survival Guide… by Michele Pavlyak is a hard hitting, common sense handbook for selecting software. The book acknowledges that software selection is more of a people decision than a technical one, and that the project team should consist of frontline personnel.

Ms. Pavlyak is even bold enough to acknowledge that the in-house systems group should not lead the project. We concur with this sentiment, as our own consulting experiences indicate the end users of systems are best qualified for choosing the right system since they best understand the business processes.

The reading is smooth, using business rather than technical vocabulary. It is apparent the author has a rich amount of practical experience and “street” knowledge, as opposed to being an academician, which is important with this type of book.

The introduction reminds us “well over 80% of software projects are either cancelled or experience significant time and cost overruns.” In the author’s opinion, this is due to a lack of communication and poor project management. The book is divided into fifteen logical chapters:

1. Separate the Tool from the Process. This is a good way to begin the book. The author uses the example of taking up the game of golf. In other words, its best to spend money on golf lessons (the process) to understand the process of golf before you buy golf clubs (the tool).
   
2. Identify the Exact Reasons You Think You Need a New System. Both good and bad reasons are listed. This is an important business decision, not a technological one. For example, the mere fact that a competitor has a new system is no reason for you to need one.
   
3. Do Not Look to the Systems Area to Lead Your Systems Change. This is the most interesting and revealing chapter. It points out the in-house information systems group is good for advice, but not for business leadership.
   
4. Build a Winning Project Team. The project team must have a good leader, and the characteristics of this leader are explained. A person who is a dedicated “change agent” and fully understands the process is the most acceptable. Additionally, a team member must represent all functional areas.
   
5. Build the Steering Committee. The steering committee is made up of top-level executives who will review the project team’s progress from time to time. The steering committee will not be involved in the minute details.
   
6. Communicate Commitments to Your Organization. This chapter is full of good advice on what makes up a good system and a good system decision. For example, always buy existing software, not promises of future “vaporware”.
   
7. Prepare for the Move. This process involves data clean-up, process streamlining, re-examining the existing systems, eliminating all unused systems, and budget restructures.
   
8. Write Specifications. This chapter illuminates that detailed needs and wants should be spelled out. It is amazing that a lot of companies start looking at systems before a specification is written.
   
9. Consider Reputable Outside Consulting Support. (For reasons beyond understanding, this was our favorite chapter.) A disreputable consulting firm will “attempt to change your mind and try to convince you to use high-risk, high-time requirement” solutions to increase consulting revenue. “A reputable firm will offer you their general recommendations. They will explain in cold, hard facts, numbers and experiential examples what they recommend and why. They’re smart enough to know not to work with any client who is destined for failure ahead.”
   
10. Do Your Homework and Learn from Users. This is very important. The best way to find out things is by talking to other people from user groups and other software evaluation organizations. Also, buy only software from true, well-established software companies.
    
11. Lock in Your Software Choice. There needs to be a formal check (in writing) between the project team and steering committee on what to expect from the software. Everyone must agree that the software supports the business and 80-85% of the needs are met and that all questions have been answered. This must be done before vendor negotiations commence. All lot of detailed advice is given on contract terms, payment terms, et cetera.
    
12. Know What to Expect from Your Organization. This chapter is an excellent discussion on company politics and leadership. We have all been there: People do not like change and there will always be some backlash. The chapter covers how to deal with these people problems, including detailed training ideas.
    
13. “Freewheeling” – When You Know You Have Lost Control. This covers more politics, which is good because most books at the academic level ignore politics. It is a short chapter, but very important because it stresses the value of standing you’re ground, keeping the black and white from being compromised. An example scenario: What if a senior executive on the steering committee is raising questions and doubts about your leadership?
    
14. The System Won’t Work When It Goes Live. Ms. Pavlyak states that new systems never work the first day. Our experience: She is right. It takes a good two to three weeks before things are normal again. In our opinion, this is due more to people problems than system problems. There needs to be a detailed contingency plan. Unless it’s a pure conversion, never run parallel with the old system because reconciliation will be a nightmare.
    
15. How You Will Know When Your Implementation Has Been a Success. If the system still works two months after implementation, it is a success. There is a great sense of pride on the part of the project team.
    

For those who wish to become enlightened regarding good systems decisions, we highly recommend Systems Survival Guide…. To request this book, please refer to: www.SystemsSurvival.com.

Quotes Worth Noting