Systems Survival Guide
for the "Systemically-Challenged" Executive
by Michele Pavlyak, MBA, CFPIM, PMP
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, click here.
Tom Chenault is the President and CEO of Chenault Systems, Inc., a database and e-solutions provider.
Reprinted with permission from Intelligent Systems, a quarterly newsletter for clients and friends of Chenault Systems, June 2001.