Avoiding Pitfalls in CMMS Implementation

The root cause of most problems with maintenance information systems can be traced to the early stages of the selection and implementation process. Here are some of the most common pitfalls to avoid.

Consider this scenario: Three computerized maintenance management system (CMMS) vendors have been invited into your organization to demonstrate their products. During the presentations they learn that other companies also have been asked to show their software. The vendors now know they must come in with the most competitive bids possible.

The heat is on for them to drop their prices and give you the best deal ever, right? The truth is they have just confirmed in their minds that, using the traditional CMMS purchasing process, there is no way they can reveal the true cost for a full implementation. All three vendors realize you need further assistance, but they also realize that if they show all these costs up front, they will not be chosen for the sale. The end result is that the buyer of the software will either miss out on its full functionality, or eventually spend a considerably larger amount for implementation.

This practice of hiding the full cost to win the bid is a big issue facing organizations as they select CMMS packages. Most first-time buyers never suspect that complete implementation is not fully covered. Most software vendors during the heat of the sale have little interest in being totally up-front about an organization’s shortcomings. Despite what vendors say about installation and implementation services, most of them want to sell software rather than fix a company’s organizational problems. This does not imply that vendors are dishonest; they are in the business of selling software, not organizational improvement.

Even knowing the fact that most vendors don’t want to get involved isn’t enough to solve the problem. What questions should be asked of vendors? What is really meant when a vendor says, “We have complete implementation services,” “we guarantee our product capabilities,” or even “we fully train your staff?” None of these statements suggests the often-painful process of changing the way an organization does business. The cost of aligning processes and software can range from half the software cost to six times the software cost if done poorly.

Meeting the implementation challenge
There are several ways to meet the implementation challenge. It takes a skilled implementation group, which may be provided as a side package consultant by the vendor to close the gap between today’s processes and the processes really needed to work with the software. Other options include a separate consultant or a trained internal team (if available).

Software projects, in general, have a history of cost overruns, misalignment, and outright failed implementations. There are many pitfalls that can be avoided if the project is planned well.

Maintenance work forces need to have quality data to perform effectively. In fact, today’s work forces are often crippled without this data. These massive requirements for information lead organizations to search out a computer system that will help them analyze and manage their business. The difficulty is choosing the best CMMS for the type of organization.

Because there are so many software choices and styles, it is hard to decide which will do the best job. There are proven methods for selecting the system, organizing the department, implementing the software, and finally reaping the benefits that so many organizations miss out on. By learning some of these proven methods, you can avoid the pitfalls of others’ mistakes.

Success rate of current efforts
Even though there is a lot of focus on selecting software, many purchased systems remain on the shelf or are grossly underutilized. Many implementation efforts still result in simply documenting work after the fact. Organizations often think that selecting and implementing a CMMS will be as easy as software is to use. This is true if a maintenance organization is fairly small and/or its needs are fairly minimal. However, the larger an organization and the more complex its needs become, the more difficult it is to find the right system to match those needs.

A full functioning CMMS is one of the most complex systems available. Couple that with the fact that there are scores of systems to choose from, and system selection alone can be a daunting task. There are a number of common approaches to system selection; some focus on:

• Choosing a system by matching capabilities to an existing system based on old technology
• Choosing a system that is glitzy and seems to provide some perceived functionality (Wow, isn’t this neat?)
• Choosing a system that meets reporting needs
• Choosing a system based on computing environment
• Choosing a system based on cost (i.e., cheapest system available or low bid)

How do you find the right system when there are several that will do a good job? They all seem to do the same things. Why not just shortcut a lengthy selection process, select one of the top systems, and move directly into implementation?

Selection pitfalls
The most common reason system selection and implementation efforts fail stems from the selection process. There is a belief that all major brands of CMMS are basically the same and that an organization should be able to just buy one and start implementing. But the real differences between systems lie deeply under the hood. The only way to find those differences is to look.

A CMMS, like any other software system, is really nothing more than a tool to help collect, categorize, organize, analyze, and manage information. You buy a tool because it provides the best functionality for the price. Shortcutting the functional details that you expect the system to provide eliminates your ability to see the differences between what seem to be very similar systems. Right from the beginning, your selection and implementation project is subject to potential failure.

The next most common pitfall is the acceptance of customization or a high level of tailoring to achieve the functionality needed or desired. There are three methods for altering the way a system functions: customization, tailoring, and configuration (See accompanying section “The Risks of Modification”). Before you commit your organization to these risks, ask vendors for their definition of these terms, to make sure everyone is speaking the same language.

In addition to the normal causes one would expect for selection failures, there are others to consider:

• Not identifying those requirements that are critical or unique to the organization and evaluating software against them
• Major selection focus not on required functionality
• High level of customization or tailoring necessary to get a system to meet needs
• Focus on software rather than business needs
• Selection grouup not listening to the end user to determine true functional requirements

Not using a proven selection process may result in selecting the wrong system.

Common implementation methods
After the selection process is complete, an organization focuses on implementing the purchased software. Successfully navigating the selection process does not guarantee that the system will be fully implemented, used, and provide the expected benefits.

There are a number of methods used for implementation. Some of the more common are:

• Going it alone, other than some vendor training
• Co-managing implementation with the vendor
• Enlisting outside implementation guidance and support
• Managing implementation internally with installation, set up, and training provided by the vendor

Implementation pitfalls

Most system failures reveal themselves during the implementation process. The major cause for implementation failures can generally be traced to not utilizing a formal selection process. Unfortunately, the results of an ineffective selection process are not manifested until well into implementation. Some do not even show up until after the system has been implemented and a situation occurs that proves to be disastrous.

Some of the most common implementation problems that individually or jointly cause major difficulties or delays, or completely stop the effort, include the following:

• Discovering the system does not provide required features or functions
• Encountering major surprises when a critical capability does not operate in the manner required
• Attempting to use the new system in the same manner as the old, i.e., automating obsolete work processes (especially true when replacing an older system)
• Misunderstanding or grossly underestimating the level of effort required. Users become disenchanted when a realization of the true effort required becomes apparent.
• Lacking a thorough plan, schedule, and objectives
• Having less than adequate staffing support
• Overloading users up front with excessive training and subsequently having problems using the system because it seems so massive and complicated.

Ensuring return on investment
Selecting and implementing a CMMS is not a simple or easy process. There are many pitfalls and problems that very easily result in a failed attempt. Early problems stemming from an ineffective selection process do not become visible until well into implementation.

Couple those with a myriad of common problems that occur during implementation and failure becomes very common. Maintenance and reliability professionals must have long-term goals in mind, focus on results, and avoid shortcuts if they are to realize an appropriate return on their software investment.

Future articles will cover the importance of a formal selection process, achieving alignment between an organization’s maintenance practices and needs and the CMMS selected, the requirements for a successful implementation and how to accomplish that in the shortest amount of time, and the “Do’s” and “Don’ts” of ensuring that the system is used effectively as an analytical and planning tool to obtain the desired return on investment.

Derold Davis and Joe Mikes are senior consultants at Westin Engineering, 11150 International Dr., Ste. 200, Rancho Cordova, CA 95670; (916) 852-2111. They both have more than 15 years of experience in providing system selection and implementation methodologies, proven maintenance practices, productivity improvement practices, and methods and strategies for increasing operational reliability and reducing maintenance overhead.

The Risks of Modification (back to article text)
One of the more common pitfalls in the installation of a computerized maintenance management system is the acceptance of customization or a high level of tailoring to achieve the needed or desired functionality. There are three methods to alter the way a system functions: customization, tailoring, and configuration.

Customization is the process of changing a system’s software coding and affecting the way it functions. It generally will invalidate the vendor’s software support agreement, pose major rework before new software releases can be installed and used, or both. The user must be prepared to take full responsibility for ongoing software support and enhancements. It is highly recommended that this approach be avoided. If you are tempted, you are probably working with the wrong system.

Tailoring generally consists of an advanced tool-set that allows changes to screen layouts, cosmetics (colors and fonts), and contents; usage of user-defined fields; and even modification of system functionality. The tool-set is provided by the vendor and can take many different forms. This is an intermediate step between configuration and customization. Knowledgeable users can affect some of the more simple changes; others require detailed knowledge of the vendor’s tool-set. You can get into some trouble with this approach because you modify the way the system works and manages data. Changes made to the way a system functions must somehow be incorporated into new software releases.

Configuration is using vendor-provided option and feature selections to affect the way the software functions to more closely match your desired business environment. This generally consists of making choices from a list provided by the vendor or by specific data in a vendor-formatted file. For example, if you wish to use ABC classification capabilities for inventory management, you may be able to activate that feature by selecting “yes” from an options menu. Then you would provide the A/B and B/C breakpoints that the system will use to recalculate or initially establish ABC classes. Or, you could leave that feature inactive. You cannot get into too much trouble with this approach, other than making a wrong selection and having to backtrack and correct data.

All customization and certain levels of tailoring will result in a system that either the vendor will not support or is extremely difficult to incorporate into new releases. If knowing these technical terms is not challenging enough, software vendors often use the terms interchangeably. Before you commit your organization to tailoring or configuring a system, ask vendors to define these terms so you are speaking the same language. MT