Automating facility management tasks promises financial gain, better quality and service, and improved safety. The past decade has seen tremendous gains in technology with Web-based systems, more powerful hardware and more sophisticated software. However, technology alone isn’t enough; the primary vehicle for achieving value through automation is process change.
Automating facility management processes is similar to losing weight. Just as purchasing a membership in a health club does not translate into weight loss, investing in technology doesn’t necessarily improve quality and reduce effort. With automation, changes in culture and processes are the most important factors for success.
All facility management automation projects, large and small, include a number of steps. The most successful projects involve multiple phases: a pilot, an initial rollout of the system, and subsequent periodic system adjustments based on new processes and technology.
Step 1. Identify business objectives. The problems to be tackled should be identified clearly and concisely. The solution should address the objectives of the organization, the division and the department, as well as the causes of the problems.
Step 2. Conduct a needs analysis. This step involves reviewing existing technology and documenting existing processes, work flow, task flow and the level of effort needed to perform each task. The needs analysis should integrate existing systems with the task flow to create an information flow. The needs analysis should also integrate the business objectives with the information flow.
Step 3. Define system requirements. There are two parts to this step: technical components and process changes. Both have to be clearly defined, and each has to be defined as it relates to the other.
Step 4. System acquisition. As with Step 3, both technology and processes should be addressed. Although it is natural at this point to concentrate on technology, the process cannot be ignored. All levels in the organization and all affected departments must buy into the new process.
Step 5. System implementation. Technology and process change are key. These need to be synchronized.
Step 6. Process and system evaluation. Both technology and the new processes need to be evaluated after initial rollout. Usually, systems are implemented as pilots. After a short trial period, the technology and the processes are adjusted, and the system is rolled out. After the initial rollout, the system should be reviewed at least annually to allow for new or changing business objectives, process improvements and new technology.
Step 7. Process and system adjustment. Once the evaluation is complete, then the overall system — both technology and processes — is adjusted to meet the new objectives.
Although technology is usually blamed, it is not the primary reason that a project fails. Choosing the wrong technology has economic consequences. Almost any system can be customized to perform any task given enough money. The primary reason that projects fail is human error, not technical failure. Many human errors contribute to project failure, including:
Most of these errors can be avoided by identifying the cause, rather than the symptom, and understanding that technology is a tool for adjusting the process to address the cause.
The most successful projects are ones that adjust quickly and appropriately to problems that are sure to arise. An appropriate response is one that supports both the project and the business objectives, as well as the process and culture changes.
Most appropriate responses are common sense. The pitfall for the typical projects is not a lack of common sense, but the use of common sense to solve the wrong problem. Most solutions address the symptom instead of the cause.
For example, suppose a single day is allocated for training the administrator in data entry on the new system. After one day of training, the administrator still can’t use the new system to perform the job. A typical diagnosis might be that the training was inadequate, that the administrator needs a repeat class or that the system is at fault. Maybe the budget is extended to repeat the training, or maybe the administrator is told to spend time learning independently, so the budget is not exceeded. Perhaps the programmers are asked to adjust the program based on a particular complaint.
The problem, however, is not a poor trainer, a poor administrator or a poor system. The problem is that the administrator was not involved at the beginning of the project and did not participate in designing the system. The system does not address the administrator’s job requirements. The administrator has no stake in the system, and the system is not optimized to support the process change. The trainer typically is an expert on the system, but usually knows little about the required process change. Keeping the primary focus on the value of process change rather than the technology would have prevented the problem.
Given that example, the best solution is to treat the system as a beta system. Work with the administrator to understand the process change issues. Typically, this results in minor system adjustments and a smoother transition to the new process and technology. While the schedule and the budget might be extended, the project will end up adding value to the organization — the primary objective of the project.
In the most successful projects, technology is viewed as a catalyst and a tool for process improvement. Viewing the technology as the solution to the problem or as the primary value will almost always guarantee poor results. Some projects succeed in spite of themselves because the operators, in their frustration, find creative ways to use the system in unintended ways to improve the process.
Once process improvement is the primary focus, other factors critical for a successful project can be addressed. They are:
Chris Keller is president of Integrated Data Solutions, based in Langhorne, Pa., which focuses on CAD and CAFM/CIFM.
Why the typical project goes awry
There’s an old joke that goes like this: “What are the five phases of a project? Euphoria, disaster, search for the guilty, punishment of the innocent and reward for the uninvolved.” In some cases, that’s not too far from being true.
The worst case runs something like this: An event, usually negative, puts the focus on a poorly performed task. Lack of technology is blamed rather than poor process, management or execution. Attempts to solve the problem focus on a single task and not on all of the interrelated tasks.
At this point, management asks vendors to demonstrate solutions to the problem, which is narrowly defined as a single task. Management then decides which tools the operators need. The solution is sold by a salesperson who doesn’t know the process and to a manager that doesn’t know the system. Neither person understands the technology or the impact on the business processes.
As the system is put in place, the operators point out flaws. Change orders that fix these flaws cause the budget and schedule to be exceeded. Of course, there are no instant results because of the time required to adjust to the new process. As a result, the project is deemed a failure, which is blamed on the technology, the technical team or the project manger. The technology team, whether internal or external, claims that the technology isn’t being used correctly. Meanwhile, the users become disenchanted and blame the system. In the end, the system becomes “shelfware” and facility management automation becomes a dirty word.
That series of events may represent a cynical version of project management, but it’s easy to see that projects often go as planned but results are nowhere near what was promised by the technology team.
The bottom line is that almost all projects begin with two mistakes. The first is to focus on the symptom rather than the cause and the second is not recognizing that most of the value arises from the way that the technology facilitates process improvement, and not in the technical solution. |
