In our prior post, Why Asset Management System Implementations Fail – Part I, we described the roles of the key players in implementing asset management system software. Each party brings a different skill set to the table which great facilitators strive to recognize. These skill sets are used to provide the expertise and buy-in from others.
Critical Points of Failure
At the same time, organizational leaders must be wary of as many crucial failure points as possible. Some of the more notable points of failure for an implementation are:
- The scope of the project is not adequately defined. This occurs when the objectives of the customer and the vendor do not match up. For example, the vendor brings in an energy efficiency expert to map out a plan, but the client really wants an automated work order system. The result is not having the right tools or resources for the task at hand.
- The low hanging fruit is not being collected. Recognize that 80% of the benefits come from 20% of the system; therefore it makes sense to give the 20% a higher priority.
- Unresponsive technical support or operational staffs. Staff can be unresponsive for any number of reasons ranging from a personality conflict to just having a really bad day. Once the trust is gone, almost nothing can bring it back (Something Deloitte and SAP should have recognized early on). All vendor staff or consultants should know basic problem resolution techniques.
- Benchmarks are not set. We live in a show me the money business world. To avoid show stopping surprises from the customer, it is important to be able to measure the success of the implementation at given time frames. My guess is this was not adequately done with Marin County.
- Training is ineffective, delayed or pushed aside. Asset system training is the most underestimated value of implementation. Ineffective or non-existent training will result in lower system adoption rates, end user resistance to using the system, fewer people having a strong working knowledge of the system, and far less of the system being utilized.
Because training is very labor intensive, it is often front loaded and intense. This brings out other issues such as the staff’s ability able to retain more than 10-20% of what has been taught and a significant dependence on vendor technical support. If turnover is a problem for the customer it is possible that within a year or two, no facility employee will have sufficient system knowledge to accomplish the desired objectives.
- Running out of time and/or money to collect asset detail set-up. System output is only as good as the information fed into it (garbage in=garbage out). Collecting asset detail is a time consuming process and often requires that manpower be taken offline to gather the needed information.
For example, a facilities manager might be expected to use their maintenance teams to collect asset detail. But if they do this they may not have the resources to perform maintenance and repairs when needed. Without careful planning, resistance to the new asset management system software will grow.
- The emergence of Dragons.
A dragon is a person who is either resistant to change or feels threatened by change. Left unchecked, they bring in unwanted negativity that can derail an implementation by encouraging others not to buy-into the program. Dragons can normally be stopped by including them in the implementation or selling them on how the change will help them do their job better.
- The operations team is not empowered to make the necessary changes to processes. The operations implementation team has to have the ability to draw upon whatever resources they need to execute change. When cooperation with the implementation team is optional, the plan will unravel.
Why Setting Expectations are Important
Many of the points of failure can be addressed by the vendor making sure they have a clear understanding of the customer’s expectations for better asset management and measuring results. Other issues, such as unresponsive support, are an opportunity for vendors to exceed customer expectations. My experience leads me to firmly believe that clients are more likely to leave because of how a problem was handled then over the problem itself.
As mentioned previously, the setting of expectations begins with the vendor salesperson and the executive or decision makers for the customer. The process does not stop once the implementation has started. This is because of things rarely go according to plan. Parties should be willing to adjust their expectations should unanticipated events occur.
Many of the actual customer expectations are going to be handled with the sales contract. It is not possible for me to list all the items that could be in a contract but it is possible to identify a few of the major expectations.
Expectations that Should be Addressed
- The overall scope of the implementation including who will be involved and what they will be accountable for.
- A listing of customer objectives such as work order automation, knowledge transfer, space planning
- A listing of vendor responses to the customer that describes what can be done to meet the customer’s objectives such using mobile handheld devices, document handling and so on.
- How much customization will be required and what are the costs.
- Who will perform the set-up of the asset detail (customer staff, vendor, 3rd party)
- The amount of training and the realistic results of proposed asset management system training.
- Who will be trained, how and where will this occur.
- How often will they be retrained.
- Roll out schedule for large organizations or multiple properties.
- Benchmarks of success, how will the client know the system is working as sold?
The purpose of these items is simply to make sure that the vendor understands the clients expectations and that the client is fully aware of the changes being implemented and what is required on their part to make this occur.
By understanding the roles of the players, critical points of failure and expectations, clients and vendors can now review their resources to see if a third party is needed. The final post of this series will take a look at some of the reasons a 3rd party may be needed to ensure a successful implementation.
Share with us the problems with implementations that you have witnessed. How many of the issues could have been resolved with better communication?