Steering Clear of Software Troubles

Large-scale software installations sometimes bring nearly as much pain as gain. Five steps can help facility executives avoid headaches

By James Piper  

Over the past 20 years, the capabilities, complexity and cost of facility software systems have increased exponentially. Today, most facility executives understand the benefits that software tools can deliver. But not all installations deliver on their promise.

It’s no surprise that the most successful systems are the ones most carefully planned. The following five steps can help guide the planning process.

1. Stay Focused on Needs

Perhaps the single most important step is needs identification. Software systems can do just about anything related to the operation of a facility. But not all facilities need all of these capabilities.

A system selected for its bells and whistles is often overly difficult to install and operate; users become frustrated and money is wasted.

Start by identifying all functions the new system will be expected to perform. Rank the importance of each function. While hundreds of systems are available, not all systems handle all functions equally well. Identifying the needs of the new system will help the team to select the system that best matches their requirements.

It is important for the team to remain focused. Too often teams identify every possible function as a need. In reality, most organizations’ needs are fairly limited. To help keep the team focused, create a statement of 25 words or less explaining why the software is being purchased. Constantly reviewing this statement will help keep the team focused on organizational needs, particularly when they are reviewing proposals from various system developers.

Systems should be evaluated largely on how well they meet the needs the team identifies. Additional capabilities beyond these needs might look impressive in a proposal, but will offer little value to the organization.

2. See it Firsthand

When evaluating different systems, it is very important that team members visit sites where the software has been operating at least one year — sites that are similar to the one where the system will be used. These site visits, while time-consuming, allow team members to see first hand how well the system performs in a real-world application.

Site visits also provide valuable information on how the new software will change operations in the team’s facility. Each software program has its own set of rules and procedures that must be followed when collecting, entering and using information. It is highly unlikely that any organization will be following all rules and procedures required by the software. The type and quantity of information gathered while performing work may change. Maintenance priorities may shift. There may be new ways for tracking labor and materials and charging them to projects. Accountability will change. How much the organization will have to change will depend on the software package selected.

3. Lay the Groundwork for the New System

Organizations, including facility departments, develop a certain amount of institutional inertia. This inertia produces a strong resistance to any change in operations. Unless that resistance is addressed early in the planning process, it can undermine the new system.

That resistance can be compounded by fear — fear that the new system will make jobs more difficult, displace some workers, or be used to measure productivity and identify employees performing below expectations. A good portion of this fear may in fact be justified.

The track record of the organization may reinforce these fears. It is not uncommon to find that an organization has gone through a major software implementation several times in the past. Packages are selected, purchased and installed, only to be abandoned, perhaps because the software was deemed unsuitable for its intended purpose or because it was too expensive to operate. The result is that any new effort will be viewed as more of the same.

Facility executives should recognize that resistance and fear are natural and should actively work to counter them before the system is installed. One strategy is to involve system users. Employees are not blind to the faults of the existing system. In most cases, they have the most realistic ideas of where improvements can be made.

A wide range of users should be involved in the system selection, beginning with the process of defining needs. While upper level managers may have a good understanding of what they want the system to accomplish, it is the system user who really understands how a particular system will affect operations.

4. Train, Train, Train

Training is another way to help overcome resistance. Training, when conducted properly, will also help eliminate many of the frustrations typically experienced when new software systems are installed. Equally important, training will help users recognize ways the software can benefit them and the organization.

Training will be needed in all facets of the new software. All users must be trained in basic operations, from data entry to data access. Maintenance planners must be trained on how to use the system to its full potential. System managers must be trained on issues of security and data integrity.

The team will have to address several training issues when evaluating software packages. One is timing. There are three distinct periods for training: during development and installation; when the system is brought on line; and after the system is operational. Training during development and installation will help prepare users for what is coming, but it must be carefully scheduled. If it is offered too soon, much of the information will be lost before the system becomes active. Too late, and users may be overwhelmed with other training activities. But if training doesn’t occur until after the system has been activated, users may be intimidated or make errors while using the system that damage or corrupt data. The best training involves all three periods, with programs and users selected based on needs.

5. Look Down the Road

Before a system is selected, the team must consider what will happen once the software package has been purchased and installed. Will the developer support the system? How often will software upgrades be issued, and how compatible will they be with data that has been collected using the previous version of the system? How expensive will those upgrades be? Will they be mandatory? Does the software support open standards or will it lock an organization into a proprietary system?

Look at the track record of the developer. During the site visits, talk with those responsible for the operation of the system. What have their experiences been with the developer once the installation had been completed?

User groups, which have evolved for most large-scale facility software systems, can provide valuable information about the operation of the software and the performance of the developer, both during and after installation.

Time spent investigating these issues early in the selection process will help to minimize problems once the system is up and running.

Make it a Team Effort

One of the biggest mistakes that facility executives make when implementing a large-scale software program is to assign project responsibility to a single person. That individual is expected to define the needs of the system, evaluate options, select the best system and implement that system — often in addition to other duties.

A far better approach is to bring together a team with different backgrounds and responsibilities. Typical areas that should be represented on the team include management, maintenance, purchasing, IT and potential users of the system. While one individual may be designated to head the team, the project’s planning and implementation must be a team effort.

— James Piper, contributing editor

James Piper, Ph.D, PE, is a writer and consultant who has more than 25 years of experience in facilities management. He is a contributing editor for Building Operating Management.

Contact FacilitiesNet Editorial Staff »

  posted on 8/1/2006   Article Use Policy

Related Topics: