This chapter is from the book
This chapter is from the book
This chapter is from the book
CRM Implementation
As we discussed at the end of Chapter 7, CRM is usually a corporate program made up of many projects. For CRM point solutions that deliver finite functionality, one well-run project might be enough. Each CRM project should focus on implementing at least one defined requirement. Whatever the complexity, CRM development should be evolutionary and multi-tiered. Figure 9-1 describes a departmental CRM program and its associated requirements.
){kind=link}
Figure 9-1 CRM program and requirements
Understanding the complexity of your CRM program is critical to planning your CRM project. For instance, if CRM is an enterprise initiative, there could be dozens or even hundreds of discrete requirements across the corporation, rendering project-planning orders vastly more complex. If, as in Figure 9-1, the program is departmental, each requirement will eventually be deconstructed into a number of different functions, revealing its inherent complexity and the development resources it will require.
Scoping and Prioritizing CRM Projects
Biting off all the requirements listed in Figure 9-1 would not only be dangerous; it could sabotage a company's entire CRM initiative. After you list your CRM requirements and have a good idea of their required functionality, the CRM business sponsor or steering committee can actually cast them into discrete projects.
Surprisingly, many CRM sponsors and project leaders forget this step and move straight toward trying to deliver the sum of all listed requirements in one fell swoop. Without scoping and prioritizing CRM projects, project managers lack overarching direction for prioritizing development activities, and application developers are free to arbitrarily add and change functionality during development. The results are usually disastrous. A scoping activity ensures that CRM projects are defined based on discrete requirements and are circumscribed around delivery expectations.
Requirements can evolve into individual projects based on demand urgency or perceived value or based on implementation complexity.
In the case of demand urgency, the customer support department might be overburdened. Thus the requirements pictured in Figure 9-1 might be prioritized in the following way:
Implement Web-based self-service and FAQs.
Offer Web live-chat service and support.
Support outbound message management.
Automate workforce management to optimize customer support.
Provide CSRs with on-demand customer profiles using existing data.
Provide scripting for CSRs and telesales staff.
If, on the other hand, implementation complexity is an issue, and the company needs a CRM "quick win," the following prioritization might make more sense:
Provide CSRs with on-demand customer profiles using existing data.
Automate workforce management to optimize customer support.
Provide scripting for CSRs and telesales staff.
Implement Web-based self-service and FAQs.
Support outbound message management.
Offer Web live-chat service and support.
Of course, politics figures into the decision on how to prioritize CRM projects. After all, if your customer-support vice president and call-center director are fighting over whether external data is necessary for really understanding customers, you might want to steer clear of providing CSRs with customer profiles until the issue is resolved—no matter how happy it would make the CSRs. Although formally rating the political landmines of every project could be overkill—not to mention highly subjective—knowing the political baggage that accompanies each potential project can serve as a tiebreaker.
When prioritized, a CRM requirement—or specific sets of related requirements—can be defined as an individual CRM project as shown in Figure 9-2.
){kind=link}
Figure 9-2 Delineating CRM projects
Notice that in Figure 9-2 the Web-related development has been grouped into one project. This decision was based on practical reasons—specifically, the ongoing challenge of finding available Web-development staff within the company—as well as the estimated development complexity. Projects 1, 2, and 3 are all minimally related and can each leverage existing technologies and skill sets within the company.
Who should scope a CRM project? Ideally, business representatives and development staff should discuss each requirement and estimate its value-to-complexity ratio—the higher the value and the lower the complexity, the better—with the goal of prioritizing delivery on an ongoing basis. Most CRM scoping activities focus on delivering initial applications in order to hand over a "quick win" to the business. Applications with a high value-to-complexity ratio should rise to the top, and others can be prioritized accordingly.
The complexity metrics will vary according to the availability of your company's existing technology and staff resources. For instance, companies that already have robust customer databases won't rate customer profiling to be as complex as those who must start from scratch.
To correctly scope a project, simply rating its functional complexity is not enough. Ideally, you should understand the following:
Specific technologies that will be involved in implementation
Necessary skills to implement the project
Number of staff members projected to work on the project
Number of consultants needed to supplement in-house skills
Realistic time frame necessary to deliver the first release
Organizational boundaries and potential political issues
Scoping a CRM project prior to launching development mitigates the risks. For one thing, it's much easier to develop an accurate project plan that reflects realistic resource requirements, tasks, and time frames. Justifying headcount requests to management based on the project's true scope is also easier. Finally, hiring becomes more straightforward, because the true skills necessary to develop the CRM system are clearer than they would have been if you had simply gone straight to implementation. In fact, failure to thoroughly scope IT projects is one of the principal reasons behind many of their failures.
A CRM Implementation Roadmap
Even with the most straightforward CRM products, there's no such thing as cookie-cutter CRM. Development approaches can differ according to a company's approved development lifecycle, staff expertise, and IT standards.
Despite the possible differences in CRM implementation techniques, the following proven CRM development success metrics should define every CRM development project:
Incremental development. Incremental or "building block" development means the company receives a defined amount of new CRM functionality on a regular basis. This is due not only to the inherent complexity of most CRM projects but also to the cultural issues surrounding its deployment (few organizations can absorb multiple major functional and process changes at once). Incremental CRM "releases" create a perception among business stakeholders and management of ongoing value. The alternative to incremental development is the "big-bang" approach of delivering a major new system and accompanying business changes all at once. The big-bang scenario almost always includes unpleasant surprises.
Requirements-driven development. This means developers who are creating or customizing CRM functionality have an understanding of the overarching business requirements driving CRM, as well as the necessary functionality. Developing against requirements eliminates the notorious phenomenon of "scope creep" and ensures that users get what they're expecting.
Continuous user involvement. Many CRM teams fall into the trap of involving business users at the beginning and end of CRM but rarely in the middle—during its development—where it's often critical. This means end users evaluating proofs of concept, validating data and business rules, weighing in on the contents of CRM training, and reviewing new screens or functionality prior to CRM deployment. It also means establishing regular communications between development, the business stakeholders, and the CRM business sponsor.
Implementation process rigor. Even with other CRM best practices in place, such as comprehensive requirements and an enthusiastic business sponsor, CRM development must be planned and executed around a structured development process. This is to ensure that the PMO and project managers can anticipate and accurately scope various development activities. A sound development roadmap also ensures that programmers focus less on the implementation process and more on the actual delivery of valuable CRM functionality.
Figure 9-3 illustrates a CRM development roadmap that applies some of this structure.
){kind=link}
Figure 9-3 A CRM implementation roadmap
Within the three main project phases—planning, construction, and deployment—the CRM roadmap features steps that contain a number of fixed and variable tasks:
Business Planning
CRM business planning involves many of the steps we discussed in Chapter 7. The most critical activity at the planning stage is defining CRM's overall objectives—be they at the department or enterprise level—and delineating the requirements of each one. At the enterprise level, CRM business planning can involve the documentation of a corporate CRM strategy and the definition of the corresponding programs within it. At the department level, it can simply mean establishing the boundaries of a new CRM application.
At minimum, the business-planning phase should include the documentation of high-level CRM business goals in the form of a strategy document or business plan. This document will be leveraged at CRM's inception to gain executive consensus and sponsorship. It will be useful as a focal point for requirements-driven development and—after the CRM project has deployed an application—as a way to measure its results.
As Chapter 7 illustrated in the hotel reservation system discussion, part of business planning should identify the critical customer-focused business processes CRM will impact. Where they are straightforward, you might decide to redesign these processes as part of the planning activity. More often than not, companies planning their CRM projects realize that rather than simply automating existing business processes, they are defining those processes for the first time.
Depending on funding and sponsorship requirements, CRM business planning might optionally include ROI estimation or cost-savings projections.
Architecture and Design
The need to plan CRM architecture and to design an implementation strategy is what makes business sponsors and project leaders shudder and go straight to technology selection hoping for a miracle. The architecture and design step is painful, but it's worth it.
This step identifies the business processes the CRM product will support. It involves listing the specific functions that will need to be implemented—and how—ultimately giving you a good idea of CRM's impact on the organization and various technologies.
Inventorying the range of corporate areas CRM will affect, as well as those that will affect CRM, is a critical activity. At the end of this step you should be able to answer the following two questions:
What technologies and processes do we have in place that will be impacted by CRM?
What do we need that we don't have today in order for CRM to work?
Relative to existing technologies, try to project CRM's impact on your current systems. Your IT organization should be willing to do this—and in return it won't be blindsided by CRM after it's been developed. Impact analysis can mean listing current systems—for instance, you might need to know a bit about your company's existing call center operational system before you can understand how candidate CRM technologies will link to it. Indeed, a range of existing technologies, from ERP systems to current marketing automation technologies to handheld computers, are likely to be touched by CRM.
After the system impact of CRM is well understood, an IT architect can draft a CRM architecture illustrating the appropriate linkages. Integrating corporate systems that exchange data—even if the data isn't formatted consistently—is known as enterprise application integration (EAI). It's a truism of business that different corporate systems store and use data in different formats. The term EAI denotes the integration of often disparate corporate systems that routinely exchange or share data. This means moving data between systems, as well as transforming that data so these systems can understand it.
The letter depicted in Figure 9-4 is from an online retailer that is doing neither CRM nor EAI.
){kind=link}
Figure 9-4 Neither CRM nor EAI
This letter was included in a product delivery and represents a veritable smorgasbord of CRM don'ts. The first one is that the company's online ordering system is obviously not linked to its inventory system. (The fact that the company happens to be a high-profile dot-com with an edgy Web site and slick e-mail marketing campaigns is not evident in its post-sales customer support.) The customer should have been notified of the out-of-stock items at the time of the order, not upon delivery of the remaining items.
The company might believe that, had the customer known that not all of the items she ordered would be in stock, she would not have placed the order at all. Perhaps some of the out-of-stock items the customer wanted were in some way related to the items that showed up on her doorstep. Or perhaps the company intends to link its various operational systems together but hasn't had the time. Either way, this company has successfully achieved these detrimental outcomes:
Sending its "valued customer" a form letter and thus not differentiating her
Putting the onus on the customer to follow up on the desired items
Failing to provide similar levels of sales and service. (Notice the company's customer service hours. If the customer lives on the west coast, she only has around 5 available hours to contact the company by phone—but she can still shop on the Web at any hour!)
Losing a "valued" customer
EAI is important to CRM because, no matter how successful a new marketing campaign or how polite the (albeit mass) marketing message, if internal systems cannot share data, vital business knowledge could be lost and customer service undermined. If the company truly had EAI, its inventory system could alert its customer support system when the desired items came back in stock, allowing a CSR to notify the customer and make a sale. It is for this reason that many companies undertake EAI as a preparatory step toward CRM.
For new CRM functionality, you'll also need to understand what data to consider. For each business requirement, one or more data requirements will result. For instance, if survey data is to be incorporated into customer profiles, which specific data elements should be collected? Will you need to collect external data such as third-party householding information or competitive intelligence data? Of the data collected, what should be displayed to CSRs? To marketing staff? And what systems will deliver that data?
A significant part of defining data requirements involves addressing the actual meaning of certain data definitions. Is there consensus across the business that the term "revenue" means booked revenue, or might it imply billed revenue? Does a "new customer" have the same attributes in the sales organization as in customer support? To many in IT, documenting data definitions smacks of cumbersome metadata management and documentation projects. However, it's more about simply gathering consensus and enforcing consistent business terminology, whatever form that takes. If information is indeed a corporate asset, as we discussed in Chapter 7, consistent and sustainable data definitions are essential.
When you've completed an impact analysis, you can begin prioritizing projects according to business requirements and staffing your development projects, as we discussed earlier in this chapter.
Technology Selection
As Chapter 8 explained, CRM technology selection can be as simple as choosing an off-the-shelf product or as complex as a comprehensive evaluation of various CRM systems integrators or ASPs. If you've bitten the bullet during architecture and implementation design, understanding CRM's impact on existing systems and its requirements for new functionality, you should be in good shape to align any candidate CRM product to your existing IT environment.
Development
Development involves the construction and customization of the CRM product, using specific product features. But CRM development is more than programmers assuming center stage and writing code; it involves the integration of business processes with the chosen CRM product.
By this time, you will have already identified the key CRM business processes. Process integration means that CRM technology you've just selected integrates into these business processes. (The converse—merging business processes into the CRM product's features—forces the product to in effect define or change those processes, thereby diluting them until they are no longer optimized.)
Process integration involves ensuring that identified business processes are tested with users to ensure not only that the business processes work, but also that technology features can be leveraged in order to refine them. In other words, technological capabilities should improve, not compromise, customer-focused business processes. For instance, a campaign management product allows segment managers the opportunity to refine a mailing list before the campaign is launched—something they've never been able to do—thus refining the existing process. The same product might also allow a campaign director to monitor a campaign's success rate as it's being executed. If the first thousand prospects have been unresponsive, the manager can cancel the campaign rather than allowing it to proceed, adding another valuable option to the campaign execution process.
Refining business processes during development means iterative prototyping: from time to time programmers demonstrate interim functionality to business users. Thus business users can monitor product development and test CRM functionality during—not after—implementation. End-user feedback about CRM functionality and desired changes can be flagged and incorporated into the CRM deliverable to ensure that resulting functionality conforms to requirements and meets user expectations.
Of course, development mostly involves technical work and thus might also include such tasks as database design, data cleansing and integration, and integration with other corporate systems. The integration step can easily be underestimated, because the CRM system might need to feed data to and pull data from other systems, such as call-routing systems or existing sales force automation (SFA) tools.
Delivery
The delivery step is often overlooked or lumped into development. Basically it means leveraging the corporation's IT infrastructure to dispatch the resulting CRM software to the business users who need it. In the case of a new Web-based sales-force automation tool, the application might be announced via an e-mail message that contains a link to the new CRM Web site. If the CRM system is client-server based, it will need to be installed on individual workstations.
Often, new CRM functionality simply supplements an existing operational system and is not considered a new standalone system. For instance, a contact center representative might now see a "screen pop" displaying a customer profile when the customer calls in. In such cases, business users might not even be aware of the new feature before it appears.
In both cases, user training is paramount. Before a salesperson begins using a new SFA package to schedule meetings or a CSR tries interpreting a customer's profile, she should be trained not only in using the new functionality but also in changing the way they work so they can take maximum advantage of it. Often, a customer-facing representative having new or improved customer knowledge can alter the way she interacts with the customer. For this reason, CRM training should incorporate introductions to new business processes as well as new technology.
CRM delivery can also include user guides, job aids, and other documentation, as well as online or Web-based help to encourage users to make the most of the new CRM functionality.
Some companies go so far as having CRM sharing meetings to introduce the business at large to a new or pending system, and CRM business sponsors hold periodic update meetings, filling in various organizations and key staff members on CRM's progress.
Measurement
The measurement step brings the CRM roadmap full-circle as it evaluates CRM usage in order to refine CRM requirements. Many companies forego ongoing CRM measurement; such companies are confident they won't have to answer for their CRM expenditures. But can you truly claim your CRM program is a success if no measurements are in place to prove it?
In most cases management expects regular updates on programs in which they've invested heavily, and CRM is expensive. Savvy business sponsors define CRM success metrics as a result of the initial justification of CRM, and measure the successes after CRM has been deployed. For instance, if your new CRM system automates workflow to communicate widget defects to your R&D department, you might consider tracking the decrease in product defects and a corresponding increase in customer satisfaction for customers who have widgets. This measurement can include value quantification—such as lower support costs due to fewer support requests—and thus prove return on investment.
Another way to measure CRM's success is to evaluate how well it has solved existing business problems. If you established success metrics when you created your CRM business plan, supplement them over time by correlating them to actual results. Documenting success metrics along with their actual measured improvements is a valuable way to track and quantify tangible CRM business benefits, as illustrated in Table 9-4.
Table 9-4: CRM Success Measurement
|
CRM Success Metric |
Desired Improvement |
Measured Improvement(6 months) |
Measured Improvement(12 months) |
|
Reduction in the time required to generate customer name-and-address lists for targeted mailings. |
Campaign list generation to take 1 day or less. |
Campaign list generation takes 3–5 hours. |
Campaign list generation takes 1–4 hours. |
|
Ability to make product recommendations to customers during support request (online or phone-based). |
Recommendations result in cross-selling improvement rates of 8 percent or higher. |
Customer support cross-selling increase of 6 percent. |
Customer support cross-selling increase of 10 percent. |
|
Electronic distribution of customer sales reports to sales management. |
Elimination of sales staff responsibility to produce weekly and monthly reports, generating a productivity increase of 5–10 percent. |
11 percent increase in sales productivity and reduction of one full-time administrative position. |
12 percent increase in sales productivity. |
|
Reduction in time spent analyzing data to correct contradictory customer data from sales and provisioning systems. |
Elimination of need for data correlation by implementing centralized customer database. |
None—database pending. |
Elimination of data correlation, resulting in redeployment of two full-time data analysts. |
Improvement is usually gradual as users become familiar with new technology and business processes. An effective CRM program delivers ongoing improvements as it's adopted more widely throughout the company. The 12-month measured improvement column represents the rate of improvement since the launch of the CRM program and illustrates this incremental gain.
Measurement also includes the incorporation of user feedback to improve CRM usability and business effectiveness. As the CRM implementation roadmap shown in Figure 9-3 illustrates, CRM measurement loops back around to further CRM business planning, allowing the company and its lines of business to continually refine CRM requirements and identify new CRM opportunities at the same time. If you incorporate measurement and feedback into the planning cycle, CRM will deliver new and better functionality, resulting in small victories that add up to improved customer value.
Putting the Projects Together
After you've identified your CRM projects, your PMO or project managers can agree on an overall CRM timeline that will be enhanced and supplemented as the business uses CRM and customers begin experiencing the benefits. The projects identified in Figure 9-2 can become components of an overall CRM program timeline, as shown in Figure 9-5.
){kind=link}
The solid boxes at the beginning of each project connote the fixed amount of time allotted for the business-planning phase. This phase includes project scoping; thus project durations might change after business planning is completed. Each project will have its own development-project plan reflecting more specific tasks and resources.
Figure 9-5 CRM program timeline
A visual timeline like the one in Figure 9-5 is not only effective in managing expectations about each project's forecasted delivery time frame; it can also become the basis for a CRM program document in which the project manager or development team leader can include individual project plans, requirements documentation, and specific CRM functions and features, either as a physical document or as part of your company's web-based knowledge management infrastructure. Thus managers and stakeholders can access up-to-date information about current CRM activities.