CIS Implementation Timeframes
By Gary Weseloh, Vice President - May 2004

The length of time that it takes to implement a new Customer Information System depends on many, many different variables. If a vendor or a consultant tells you how long it will take to implement a system without knowing anything about your business, your current systems and your needs for a new system, that time is nothing more than a very rough estimate.

Consider the following matrix. Two similar water utilities, both billing for water, sewer and solid waste services, one at approximately 160,000 customers and the other at 45,000 customers, issued very detailed Request for Proposals. Both RFPs described why the utility was going out for a new CIS. These RFPs listed the concerns each utility had with its current system and current CIS data. The RFPs gave a brief summary of what would be needed for each interface and integration point. As you can see, there was very little consistency in the responses from the vendors.

Matrix: Length of Time to Implement a CIS

There are many different factors which account for the length of time it takes to implement a CIS. In all fairness, the vendors in the table above may or may not have taken all of these into account when they provided their implementation plan timeframes. These factors include the degree of change the utility is attempting to make from its current system and practices to a new system, the integrity of the data it wishes to convert, the number and complexities of the interfaces and integrations that will come with the new system, as well as product modifications or customizations that will be required, and the amount of staff involvement the utility wishes, or is able, to have in the overall project. There are many other factors as well, including the decisions/preparation around the data center and hosting location, the quality of the project management office, and the degree of involvement by the utility's steering committee.

Greg Galluzzi, President of TMG Consulting, wrote an article for Utilipoint International on April 27 discussing Why Projects Fail. Two of the reasons Greg described involve the project plan and its timeframe. The first was "Unrealistic expectations, timeframes and poorly defined costs." Greg notes here that "contracting parties frequently enter the installation phase with unrealistic expectations of the other party."

Greg's second reason was "Lack of available vendor resources." Greg points out that, especially in today's economy, the vendors may be expecting the utilities to take on more of the workload. If this isn't possible the timeframe will have to either be extended or the vendor will have to add additional resources (if these resources are available), both forcing additional costs for the project.

In a recent survey by the American Water Works Association, 30 percent of the utilities that recently implemented a new CIS said that they had a “smooth” installation. Another 45 percent said that they had a “tough but ok” installation, and 10 percent stated that they had a “very difficult or failed” installation. Of the utilities that had a very difficult or failed installation, the top reasons for difficulty were:

1. Vendor was not as helpful as needed
2. Insufficient testing
3. Insufficient training
4. Ineffective Project Management
5. Data conversion issues

All five of these reasons are affected by and affect the project timeframe.

Most of the vendors have a proven and established methodology for their CIS implementations. All of these methodologies are meant to ensure that the project is successful. And some vendors feel that their methodology allows them to complete some tasks and/or phases more quickly. When TMG Consulting is assisting utilities in the preparation of their RFPs, we frequently ask the vendors to address the degree to which they will contribute to the following typical installation activities:

• Project Management
• Installation of Hardware and Software
• Product Configuration
• Business Process Re-Engineering
• Product Engineering (modifications/customizations)
• Product Conversion
• Product Report Development
• Product Interfaces
• Product Documentation
• Product Testing
• Product Training
• System Administration
• Go Live Event
• Knowledge Transfer
• Final System Acceptance
• Lost Installation Support

The vendors' responses to these questions will indicate how well each vendor understands the degree of change that the utility is attempting to make from its current system and practices, the utility's perception of integrity of its data, the number and complexities of the utility's interfaces and modifications, and the amount of staff involvement the utility wishes, or is able, to have in the overall project.

Change is by far one of the largest variables. Granted, it is not always easy to convey in the RFP the desire or willingness that you may have for change. If the primary reason you are looking to implement a new system is to get off the old technology, or to have a system that is more reliable or easier to support or integrate with other enterprise systems, business process re-engineering and change management may not be significant activities in your installation plan. However, if you recognize that you could and should be doing things more effectively and are looking for an impetus for that change, implementing a new CIS can be a very effective change agent. But, that involves time and an extension of the project timeframe.

Data conversion is another area that drastically affects the length of a CIS implementation. Usually we see that data conversion is on the critical path, and runs the entire length of the implementation project. Many utilities are coming off of old legacy systems with data in flat files. While there is nothing wrong with this, and in itself not that much more difficult, if the system has been at capacity for some time, chances are that data is now in incorrect fields or is not standardized. There are even some methods and even specialty vendors who address these issues and can radically shorten the time to convert the data. How well the vendor understands the utility's data issues and how they approach conversion can be a big factor in the total timeframe of the project.

Many vendors are offering products that allow the utility to configure the system to work the way that best fits the utility's business practices. And, most utilities are opting for minimal product modifications. But, both approaches take time. If the utility selects a solution that can be configured and not modified, it can take an extensive amount of time for the utility's implementation team to become familiar enough with the system to understand how each configuration decision will affect the way the system will work, and also how each decision will affect future configuration decisions. If the utility seeks to modify the product or customize it to work in a specific way, those product engineering changes take the vendor time to make and test, and they also add time in the project for the utility to test those changes.

The number and extent of the interfaces and integration points can also change the length of the project timeframe. Usually, both sides of the interface have to be rewritten. Whether this is done entirely by the product vendor or the utility, or if the utility will bring in other vendors for their side of the interfaces, there can be an extensive amount of work associated with these interfaces. The simple question around staff involvement is will the staff be from the utility or will the people necessary to do the work come from the vendor? As Greg Galluzzi pointed out, vendors approach this in substantially different ways. Some vendors assume that the utility desires and will take the lead in the project management role. Other vendors feel that, in order to meet set deadlines, they should assume the lead in the project management role, or at least have a co-project manager sharing the responsibility with the utility. But if the utility's expectation is different than that of the vendor's, the project timeframe will be affected. The same is true of technical support. The vendor may assume that the utility's IT staff will handle the entire data cleanup and populate data extract tables. The vendor may also assume that the utility's IT staff or the utility's current enterprise system vendors will complete their side of all of the interfaces. But, if the utility does not have experienced staff available to do this and is expecting the vendor to supply these resources, a change to the project timeframe is the likely outcome.

There are many reasons why the length of the implementation project is important. The primary reason usually involves cost. Since every project has basic overhead, including project management, dedicated core team and other resources, the longer the project takes the more it costs. Project timeframes may also affect other practical issues. The legacy system may be failing, and the longer the timeframe, the higher the risk of failure. There may be economic reasons that the project should be completed more quickly, or extended. And, there may be political implications if the project takes longer than originally planned.

The Bottom Line
The bottom line is that utilities need to clearly communicate their current conditions, their driving forces for moving to a new CIS, and their future requirements. Vendors need to understand these considerations, and develop project plans and timeframes that address each utility's unique conditions. Vendors should not plug in standard plans that reflect a short installation period just to keep the estimated cost lower. Finally, the vendor's implementation approach, assumptions and plan should be allotted sufficient time to be discussed during vendor presentations and discussions. The vendor's Statement of Work should include a detailed project plan and timeline, and this document, along with all of the contract documents, should be thoroughly discussed, modified and agreed to by both parties.

Gary Weseloh is a Vice President and Senior Consultant with TMG Consulting. He has more than 30 years of utility experience, including the management of customer systems (CIS, meter reading, remittance processing, complex billing) at a large combination utility, consulting on mobile computing/field work automation, and extensive selection, evaluation and installation oversight projects with TMG Consulting. He can be reached at garyw@tmgconsulting.com.