Enterprise Software

Case study of a successful CRM implementation: Addressing process and technology issues

If your CIO gets the CRM bug, will you be ready? Follow our CRM case study to learn what's involved in implementing a CRM solution. In this installment, process and technology issues take center stage.


In my previous column discussing this case study, I described how our CRM implementation project began and how we addressed the concerns that arise naturally when you ask people to change the way they do their jobs. In this column, I’ll look at the project in terms of technology and processes.

Implement the underlying infrastructure
Before rolling out the new CRM tool, we had to make sure the infrastructure was in place to support it. We didn’t want users who were excited after the training to be frustrated by poor performance or downtimes. When the application is running on all cylinders, it can require up to seven servers (although more than one server can run on one physical machine). We chose to implement a scaled-down version first, which cut down on the system requirements and complexity. New, dedicated hardware was brought in for this implementation so we could have a clean machine and make sure no other application running on the same server would screw up the CRM software.

Part 3 of 4
Check out the previous installments of the CRM rollout case study:

Roll out the vanilla version first
We decided early on that we would implement the first release with as few modifications as possible. As you’ll see, this was part of a four-phase approach that ensured we would start with some quick wins, even though the software might not initially be used to its full capability. The important thing was to let the users start getting used to the software as a part of their daily jobs. We didn’t want to cause any trouble with system modifications or overly complex setup requirements.

Mirror the company’s sales process in the software
Not only had our company been working without CRM software, but it lacked a formal sales methodology as well. As the CRM project progressed, the business also defined a consistent sales cycle. The cycle consisted of processes, terminology, templates, and so on. We developed the CRM tool to support all of these aspects of the sales cycle.

It was important to integrate the software into the sales process. If the salespeople had a certain process but the tool represented the information differently, we would have been in trouble. The salespeople would have been forced to learn two processes, one to use on the job and another to use with the CRM tool. They would have been less productive in such a scenario, and their resistance would have doomed the effort.

Implement the software in a series of smaller projects
One of the most important decisions we made was to break the larger deployment project into a series of four smaller projects.

Pilot test—Our executive sponsor issued us a tough challenge for the CRM tool’s rollout. He wanted us to go from kickoff meeting to initial implementation in no more than eight weeks. We were able to meet this aggressive timeline by establishing the infrastructure and then initially implementing in a pilot group. Remember: Part of this aggressive schedule was based on implementing as much of the base product with as few custom modifications as possible. We trained the pilot group, set up all initial processes, established the base infrastructure, installed the software, and had them up and running in eight weeks.

Although we referred to it as a pilot test, the participants were live for all intents and purposes. It was a major accomplishment that really allowed the project to gather momentum for the future.

Phase I—The first formal phase involved scaling the application up to support more than 100 users in the organization. This involved deployment, training, coaching, and follow-up support. We accomplished this phase over a three-month period. Again, the initial functionality was limited.

Phase II—When we started the project, we created a list of user requirements that we would ultimately need to fulfill in order to fully utilize the software. We prioritized these requirements as high, medium, or low. During Phase II, we worked on the high-priority requests that were most time-critical. The development team added and tested these enhancements. We showed users the new capabilities and offered training classes, and then we rolled out the new capabilities.

Phase III—This was similar to Phase II, except that the enhancements involved high-priority requests that were not time-critical, as well as medium-priority requests. Again, we had a rollout plan consisting of communication, training, and installation. (We never worked on low-priority requests. They were not considered part of our scope, since there is always more important work to do than add low-priority features.)

The project concludes
The implementation project was part of a 15-month rollout effort we completed in October 2001. At the beginning, we laid out the basic strategy and approach. Then we simply executed the four-phase project against that full implementation approach. From both the IS and the client perspective, the project was viewed as a success, for the following reasons:
  • We successfully implemented and deployed the tool in a short time frame.
  • The salespeople are using it (although not always to its fullest capabilities).
  • The tool is seen as the place to go for all customer-related information.
  • All customer-related data at our company is available in the CRM tool.
  • Our managers use the tool for their sales forecasts.
  • Marketing uses the tool to manage their campaigns.

In my next column, the final installment in this case study, I’ll describe the current state of the CRM environment and some of the lessons we learned.

Editor's Picks