1. Develop a Blueprint
The scope of every project should be agreed upon in advance, so that everyone has an understanding of what you are trying to do. Include strategies, objectives, and requirements in this blueprint. Focus on who will be affected by the new system: How may users will be affected and to what extent? How much will it cost? Who will pay for it? Also consider how it will affect the utility: How many people will be affected? Where will it be housed? This blueprint should provide a broad overview and begin to define expectations.

2. Bring your utilities together
Usually the biggest issues in CIS implementations occur when multiple utilities aren't communicating effectively. Most CIS projects coordinate changes to three to seven utilities such as electricity, natural gas, water, wastewater, solid waste, drainage, and transportation. These utilities may not deal with one another on a regular basis. One of the first challenges of a CIS implementation is bringing these utilities together in the planning stages.

Galluzzi says, An effective way of opening the lines of communication is to ask each utility what they hope to accomplish with the new system, and what is driving their replacement effort." Often, with multiple utilities, not all of them are affected by the same replacement drivers. In fact, one or more may not want the system due to the difference between the benefits they'll receive from the new system and the ultimate replacement cost to them.

For example, deregulation of markets is one driver for electric utilities to implement a new system. The electric utility wants to enter the market to purchase a new system that is deregulation capable. Because a new CIS may cost millions of dollars, the solid waste and water utility may say, "We are not impacted by deregulation, therefore we don't want to spend the money on a new system."

If you understand each utility’s drivers, and make sure all utilities know what the others' drivers are, everyone will know where they stand in relation to what you are trying to accomplish with the CIS, and you can begin to sort out the pros and cons for all.

3. Decide Who’s Picking Up the Tab
A lot of times, the electric company may pay for 70% of the project and the rest of the utilities combined will split the other 30%. Galluzzi cautions, "Money can become political and provoke sensitivities around the purchase of a system." If you can clearly state how each utility will benefit, and figure out their sensitivities up front, the ride will be smoother.

4. Decide Who is Invited to Submit an RFP
Most cities are used to "tire kicking," looking at systems that have been on the market for years and seeing how they'll hold up to your requirements. When initiating procurement, you may find out these old standbys aren't doing the complete mix of things you need. At the same time, you might discover only a certain amount of vendors do provide what you want. Who do you issue the RFP out to, then?

"Usually, there are about a hundred billing and customer information system solutions in the market place at any point in time," Galluzzi states. "Of this 100, there might be 30 which may meet your needs. Of this 30, 20 of the vendors may submit proposals. Of those 20, by examining their proposal and comparing it against your stated minimum requirements (see tip #6), you can cut the number to no more than seven vendors that, before a demonstration, you really need to look at in detail and analyze their proposal. From this seven, narrow it down to one or two finalists."

Unfortunately, in Galluzzi's experience, as many as 350 RFPs have been requested during a single procurement effort. With only 100 possible CIS solutions, that's a huge number. Municipalities typically don't restrict how many RFPs they receive, but maybe that's something to consider.

5. Keep the RFP Flexible
Structure your RFP to allow flexible responses. For example, the application software and related database software are submitted by the CIS vendors; services components may be submitted by the CIS vendor or a solution integrator; and the third component, regarding hardware and system software, is bid by hardware manufacturers, value added resellers, or purchased through state contracts. Sometimes everything comes from one vendor; although the majority of the time, solutions represent offerings from several vendors.

The key to making your RFP flexible is by not restricting it to the bundled solution proposed. Galluzzi suggests, "Request a proposal consisting of a bundled solution with the ability ton-bundle and award a contract for individual components, and allow vendors to submit an alternate proposal for one or more individual solution components, i.e. server hardware, client desktops, conversion services, etc. Without this flexibility, the evaluation team may find they like the software solution proposed. However, if they don't believe the proposed solution integrator is the most qualified to implement the solution, and they would prefer the software implementation services of another company, this may cost more time. When the structure of the RFP and associated vendor proposal is restricted, the evaluation team must accept the proposed bundled solution or re-issue the RFP to solicIt solution components.”

6. Focus on Minimum Requirements Up Front
When you receive proposals for review, focus first on your minimum requirements towed out the RFPs that don't meet them. There's no need to further consider a solution if it doesn't meet stated minimum requirements; this is a time waster if proposals, that can't possibly be placed in front of a council or board for approval, continue to be reviewed and evaluated.

Galluzzi gives an example, An evaluation team decided to select an IBM AS400 based solution. Unfortunately, it was not part of the city's technical plan. When we rolled it up to the executive team for approval, the chief technology officer said, 'Not an AS400, we're not allowing that platform in our shop.' If the evaluation team had identified these types of minimum requirements up front, it would have saved the team valuable time."

Another frequent minimum requirement, which usually affects municipalities, is: the solution must be implemented at another utility similar in size and nature to the city. Making a list of these types of required minimums and initially applying these to the proposals can help you quickly identify a short list of qualified proposals.

7. Structure the One-Day Product Demonstration
For each qualified proposal, schedule a one-day product demonstration. Structure these one-day product demos to glean a set amount of information and score the vendor on the specific points of review. Assign questions or specific demonstrations desired from the vendor, such as, "Please demonstrate how to access a customer account in the new system." Make sure everyone in attendance knows your grading scale. In response to the example given, have them grade how well the vendor’s system lets you access customer accounts.

If the product demonstration is not structured with a clear scoring system, people leave the room unsure. Frequently, this leads to evaluation nightmares where people review vendors repeatedly and never move out of the evaluation stage to name a finalist for the confirmation stage.

8. Only Take One Solution Through the Confirmation Process
One mistake cities make is trying to take more than one vendor through a due diligence process. When evaluation teams insist on taking more than one vendor through the confirmation process, it doubles or triples the time required for the five-day product demonstration, client site and corporate office visits, scope development workshops, contract discussions, and installation plan development. It causes an extreme amount of work if the team can't agree on one vendor finalist.

It's strongly recommended to narrow these proposals down to one choice, with a second selected as a backup should the first one not work out. You can keep this vendor on its toes by making it clear to the first choice that their company can easily be eliminated and replaced by the second choice.

9. Allow Sufficient Time for Confirmation and Due Diligence Activities
Many cities make the mistake of moving from evaluation activities directly into contract negotiation and award of contract. A major deficiency in most procurement efforts is the lack of time spent in performing necessary due diligence and confirmation activities. At a minimum these activities should include the following:

Conduct a detailed vendor product review
Conduct a five-day detailed product review, using a combination of business process and detailed functions and features to achieve a detailed understanding of integration points and interfaces, modifications, configuration, reports, forms, and anything else concerning product implementation. Drill down to the detail of what the utilities want to customize and configure to make the implementation work for everyone. Determine the impact to your existing system and what it takes to perform activities such as convert your data, configure the system, and modify base reports. Those things are addressed in the RFP, but the answers may not be clear until the two parties, city (with utility representatives) and vendors are face to face. A detailed product review is the time to talk interactively, a way to drive the formal solution toward what you need.

Fully develop and confirm solution cost
Based on the result of the detailed product review, vendors should provide detailed pricing for identified modifications. They will come back with: “Here are the 10 modifications you are asking for and the cost.” Then you can decide, is it worth $100K to make it work this way? Often, the dollars to customize are not worth it; but this way, you can see if you want to Move forward with customization or not.

Identify organizational impact
Be clear on how the system will impact the existing environments and the business itself. Try not to focus on only the vendor side of things with hardware, software, and services. Determine if you have training facilities, if you are going to pay your workers overtime for this, how many desktop versions of required software you'll need, how the cost will impact other areas of your municipality and the utilities.

Discuss and negotiate the contract package
Because of the scope of these kinds of projects, you usually end up with many contracts within the contract package. These contracts require significant time to develop ? it can take up to four months to craft hosting or outsourced contracts, and to negotiate reasonable terms and conditions. Make sure you allow for time for creating contracts and for obtaining agreement.

10. Educate the Selection Committee
Tell your selection team what to expect and make sure they have all the details necessary to make their decision. Many times the vendor / partners chosen get in front of a council and the council has many questions. They might say, "This is a lot of money; we find it hard to spend $10 million on a system. Especially when yesterday's newspaper said the city faces $10 million in tax deficit." Though the staff might think they have thoroughly prepared the council to approve the system, be prepared to educate the council or board members regarding all aspects of the new system, its cost, and its impact on the city and the utilities. The more thoroughly they understand the ins and outs, the easier their decision will be.