January 1998 • Volume 8 • Number 1
Successful Installation and Implementation of Commercial Off-the-shelf Software:
The Non-customized Approach
The use of customized software for resource management is nearly ubiquitous in industry today. but going "customized" is not the only software option available for many firms; getting your software "off-the-shelf" also has its merits.
By Bob Cook, CPIM
The intent of this article is to provide a quick overview of those critical rules which must be followed if you want to successfully install and implement a commercial off-the-shelf (COTS) software package sometime before you reach retirement. The rules are:
- No testing allowed
- No modification/customization of screens, no matter how simple to do
- No automated interfaces, no matter the perceived necessity by some of the users
- Change your processes to those supported by the software
- Identify "Joe" and shoot him before he shoots you
No testing allowed
First let's distinguish between installation and implementation. Installation is the task of installing the software on whatever hardware you're using and making sure it's operational. For example, when you buy Microsoft Office you take the product out of the box and install it on your computer, make sure you can access it, then use it. You do not get involved in any elaborate schemes to "test" the software to be sure it "works in our environment." Remember, it's commercial software. A lot of people are already using it successfully. If that's not the case, go back and be sure you really bought commercial off-the-shelf software. Implementation is the really tough task.
Now that you've installed the software and the users have access to it, how are you going to get them to use it? Get out your copy of Daryl Connor's book, "Managing at the Speed of Change." You're going to need it.
No modification/customization of screens
Most of the newer packages allow system administrators to easily change the screen layout, rearrange fields, change their labels, hide fields, display hidden fields, etc. Don't you do it! Why? Assemble any two users and try to get them to agree on what they'd like to change, and then what they'd like to change it to. The journey to failure begins with this first step. Don't take it. No changes. Build a "cheat sheet" if you have to with a cross reference to what you call the field and what the software calls it, but don't change the screen.
The time spent in meetings on what to change and what to change it to can be much more profitably spent in analyzing your current business processes and coming up with innovative ways to improve them. If, after you've been using the software for several months, users still want to change the screens, get the "configuration management cops" to set up a procedure to evaluate and make changes. That procedure will no doubt ensure no changes are made for several more months. But remember, no changes initially.
No automated interfaces
Do not implement automated interfaces, no matter the perceived necessity by some of the users. "I'm not sure exactly what data we need, but I'm certain we need an automated interface with 'X' system." If that statement doesn't bring a smile to the face of a software developer, I don't know what will. You may want to shoot the guy with the interface requirement and the software developer with dollar signs in his eyes before you get to Joe (the person you'll have to shoot when following up on Rule #5).
Do not get sucked into this swamp. It may well be true that eventually you'll need an automated interface, but initially, figure out how to implement the system without any. If you've got to do some dual data entry, face up to it and do it. People are much more adept at adjusting to ever-changing and fuzzy requirements than are lines of interface code. Besides, after you've changed your processes and used the system for a while, some of the original "gotta have requirements" may disappear, and the real requirements will be pretty well defined by the dual or manual data entry points.
Again, initially, no automated interfaces. Trying to define interface requirements before you've changed your processes and actually used the new processes and software is high risk, very costly and consumes an inordinate amount of time.
Change your processes
Change your processes, improve your processes, but be sure the software will support the changes. Get out your "change management" tool kit.
"We've always done it that way." You've heard that before. But maybe you haven't heard, "... but I have no idea why." People won't often admit that. But, ask a few questions and you'll frequently discover most of the folks doing the work don't really understand how the specific function they're performing fits with the rest of the organization, let alone how their function supports the major business process of which they are a part. In fact, they might not even realize they are part of a business process. Here is where some education is appropriate. Before people start improving and changing things, give them a little education on the "big picture." Chances are the people who developed the commercial software had in mind some kind of standard business process and the underlying functions necessary to support those processes when they developed the software. Don't keep that design a secret. Educate the users and, more importantly, their management on the business process they're performing and how the design of the software relates to those processes. After all, even if your initial motivation to buy COTS was to save money on software development and maintenance, you implicitly decided to adopt "best commercial practices" when you decided on COTS. So adopt those practices as embodied in the overall software design.
Identify "Joe" and shoot him
Identify "Joe" and shoot him before he shoots you. Every organization has a "Joe." He's the guy who's been with the company since it started and the guy everyone turns to when something really important just has to get done. Chances are the software and process changes which will accompany it are going to upset Joe's world. Joe is not going to want to change. Remember, he's been operating like this for years, and he's been very successful. Joe is the guy who's going to be sitting back and waiting for the implementation problems to surface, and they will. Joe will have you in his sights, just ready to shoot at you every chance he gets. After all, it's his perception that you're shooting at him by making all these changes.
At this point, senior management has a tough decision to make. How are they going to deal with Joe? If they can't or won't deal with Joe, he may succeed in shooting you and cause the implementation to fail. You've got to identify Joe, which is very easy to do, and convince senior management to either convert Joe to an implementation supporter, move Joe to a position of no influence, or simply thank Joe for his years of faithful service and ask him to retire. If Joe can't or won't retire, he'll have to be fired. That's a tough position to take, but talk to managers who have successfully implemented a major change in their organization. Most will admit they had a Joe, and that if they had dealt more decisively with Joe at the start, they would have made their change process significantly easier.
Shoot Joe before he shoots you! Hopefully your "change management" tool kit includes this level of commitment to consequence management from senior management.
Bob Cook, CPIM, is a project manager for Lockheed Martin Services Group. He is not a software developer. He is currently engaged in a COTS implementation, trying to get off the first shot. (Note: Bob would like to acknowledge the contribution of Chuck Diaz, a fellow implementor, in introducing him to the concept and character of "Joe.")
Copyright © 2020 by APICS — The Educational Society for Resource Management. All rights reserved.
Web Site © Copyright 2020 by Lionheart Publishing, Inc.All rights reserved.
Lionheart Publishing, Inc.
2555 Cumberland Parkway, Suite 299, Atlanta, GA 30339 USA
Phone: +44 23 8110 3411 | br> E-mail:
Web: www.lionheartpub.com
Web Design by Premier Web Designs
E-mail: [email protected]