A staggering number of CRM projects fails to meet the objectives. This statistic needs to sink in before you attempt to deliver a CRM project. Your project doesn’t have to become a statistic as long as you follow some tried-and-true best business practices, including starting with a pilot project. You should select a minor project from the perspective of functionality and impact on the organization, but one that will prove the technology and the related business processes.

It’s a given that in order to be successful in any project, you have to build on solid ground. CRM projects are no different than any other projects — from this perspective at least. Here is a recipe for building your project on a solid foundation.

Long-Term Roadmap

It’s imperative to start with a long-range planning exercise. The best way to go about this exercise is to create a multiyear roadmap. This roadmap will help coalesce the business thinking and distill that thinking into an executable plan. The multiyear roadmap will contain the entire spread of functionality the company wants to implement, and also include the steps and milestones to get to the end goal.

However, the scope of the roadmap may look daunting initially — and there’s no better way to make it more feasible than by getting some small successes under your belt very quickly. The best way to proceed in order to achieve these small successes is by first employing a pilot project.

Another reason to start with a pilot project is the fact that often the CRM systems are relatively new and the underlying technology is unproven (at least within many organizations). Testing the change management capabilities of your organization is another reason for starting with a pilot project. For example, if you’re thinking of rolling out a Sales Force Automation (SFA) system, you first have to make sure that your sales force is trained in the sales process and understands the benefits of the SFA system for the company. They should also understand what’s in it for them.

Without performing the required due diligence, your project may be doomed from the get-go. Starting with this pilot project will allow you to test both the new technology and the change management readiness of your organization in one swoop. While this may seem very theoretical, an example of how you can actually do this in real life would be to start your SFA implementation by rolling out a straightforward Contact Management system. Only after that functionality is proven and your entire sales force is on board, conscientiously using the system, should you proceed with implementing the rest of the relevant functionality, such as Opportunity Management.

I’ll exemplify this approach with a sample roadmap for the Acme Company (Figure 1).

Figure 1

Sample Roadmap for Acme Company

The underlying assumption for this sample CRM project and roadmap is that Acme Company already has an SAP ERP back end that takes care of the logistics execution part of the business (e.g., Sales and Distribution, Finance, Production Planning, and Materials Management). The SAP ERP system will also be the source of most of the master data for the project (such as customers, products, and prices). Assume the company is not capturing contact persons in SAP ERP, but only in SAP CRM. Eventually, these contacts can be sent to the SAP ERP system if so desired.

As you can see in Figure 1, the Acme Company is taking a cautious approach to implementing SAP CRM. The company started by strategizing for its long-term CRM needs by running a series of workshops with all of the relevant departments for such a system: Sales and Marketing, Customer Service, Quality Control, Finance, etc. This strategic exercise has provided the required information to build the roadmap, and as you can see from this example, the hypothetical Acme Company is a sales- and marketing-driven company. Typically, any such roadmap would span several years, but in my very simple example I am only talking about a couple of years.

The Importance of the Business Case and Return on Investment

The business case and the return on investment (ROI) document are probably the most important documents that your company will generate before the project even starts. The two documents are quite different, but they’re an inseparable pair of deliverables that work toward the same goal: obtaining high-level support for the project in your company and supporting the funding request.

Each company has different standards for generating business cases, ranging from short and descriptive ones to comprehensive and highly structured documents that are more like plans for delivering the project.

Here’s the minimum information that your business case should contain:

• What the proposed investment is all about
  
  
• The strategic reasoning behind the project
  
  
• The value created for the company and the associated risks

Ideally, the business case should also contain enough information to convey the message that the project will be well-managed, the outcomes will be measurable, and the costs will be controlled. It is very helpful if you include information about the prime stakeholders, such as the project sponsor, project manager, and the most important steering committee members. Based on all of these content areas, a strategic investment committee that has to review and prioritize several such business cases should be able to make a decision on what the company will fund. Do not underestimate the importance of a well-written and executive-sponsored business case, because many valuable projects have been put on the backburner due to unclear business cases or a lack of executive support.

At various stages in your project (depending on your implementation methodology of choice), you should reopen the business case for review to make sure that you either stay true to the original intent behind the project or conscientiously agree with the project stakeholders to change the project “story.” If the business imperatives will change during the course of your CRM project, your project and its business case will have to change accordingly (e.g., a new division is acquired and you have to include some of its distinct requirements).

When generating the business case, ensure that you won’t succumb to the planning fallacy, where the task at hand is evaluated without regard to the actual environment. The optimism bias often has to be toned down because you can be sure your project will not get all of the top skilled people it needs, and it will always have to compete for resources with other equally important projects.

You can get more details on how to generate great business cases from a variety of sources. One of these sources is the U.K.’s Office of Government Commerce (www.ogc.gov.uk/documentation_and_templates_business_case.asp), where you can find good information on the topic, plus a couple of business cases templates.

Now I’ll discuss the ROI document. In theory, this document is a more straightforward document than the business case, but in reality it is a more controversial document. The calculations are typically straightforward, but where the rubber meets the road are the assumptions used for those calculations. Because this document will be reviewed by your investment committee with the business case, it will receive a lot of scrutiny. That being said, it is mandatory to have the Finance department involved in generating the ROI, along with the department(s) your SAP CRM project is intended for. To give you a simple example of why the ROI document is controversial, consider the following scenario.

Your company is gearing up to implement a sales force-related SAP CRM system, a so-called SFA application. At the same time, your company is changing the underlying sales process and methodology and rolling out a new training program. Because the training and the sales process and methodology work are typically done by the Sales department itself, the business case and the ROI document will be written from an IT perspective (intrinsic to the SAP CRM project itself). The Sales department will predict a certain sales increase over the next five years, and your SFA application ROI will take that net sales revenue increase as one of the parameters in the ROI. The IT department will estimate the cost associated with the project, including the five-year depreciation and the maintenance costs over the same period. The ROI calculation will then be relatively straightforward, but can you really attribute the forecasted net sales gains exclusively to the SFA system? Should you split that revenue gain between the training program and the inherent improvements due to the new sales methodology?

In conclusion, it’s imperative to gain the Finance department’s input when putting together the ROI, as that will add credibility to the document. Because the executives are all aware of the degree of uncertainty involved with an ROI document, the business case will probably have much more weight in assisting the investment decision process than the ROI (which is not to say that your ROI shouldn’t receive proper attention).

Start with a Pilot Project

The Acme Company’s roadmap is relatively straightforward, and I’ll start with a Contact Management pilot project — the most cost-effective way to dip the corporate toe into the SAP CRM waters. This pilot project will focus on proving the underlying CRM technology, and it will be rolled out to a small group of sales reps (a mixture of computer-savvy and less-computer-literate people). Of course, before you can roll out this functionality to the pilot group, you have to implement the SAP CRM system and connect the existing system to the back-end ERP. These tasks (e.g., installing the software, configuring the connectivity between the various components of your SAP ecosystem) are typically taken care of by your Basis team.

Design and Implement the Functionality

The Contact Management functionality consists of the customer contact data in the SAP CRM system (e.g., name, address, phone number, email address) and also eventually integrating this data within the Microsoft Exchange server environment (Outlook 2003 and above). While this example is a simple one, each piece of functionality requested by the business will have to be documented as specific business requirements. Good business requirements will spell out the actual need, and not the means to fulfill that need.

Train the Pilot Users

After configuring this functionality, Acme Company will train the select group of pilot users to use the software. After the pilot go-live, project management and the key stakeholders will constantly monitor the usage of the system. It is important the pilot users are constantly using this system because you want to get the maximum bang for your buck from this limited number of people. The feedback provided by this group is going to be critical for refining the piloted application and understanding the user interaction with your new system.

Incorporate the Feedback

During the incorporating pilot feedback phase, the Contact Management functionality is refined and the usage patterns are examined. Any tweaks in the system can be done during this period, and any changes to the user interface are implemented before rolling out any new functionality.

Revise the Roadmap and Next Steps

At the end of the pilot project, Acme Company goes through a series of workshops to revise the roadmap. One of these workshops will deal with the lessons learned from the first SAP CRM project. Assuming the roadmap still holds water, the company proceeds with implementing Phase I — Lead Management and Contact Management. Because the Contact Management functionality is a rather small piece, it can be incorporated in the Phase I rollout (there is no need to independently roll out the Contact Management functionality to the entire remaining sales force — this can wait for the Phase I rollout to the entire sales and marketing user base). This rollout is comprised of the entire marketing and sales user base.

At the end of the rollout, all of the marketing and sales reps from Acme Company should be up and running on the new SAP CRM platform. They can create and maintain contact persons in SAP CRM, download these contacts into their Microsoft Outlook systems, and collaborate on the leads (which will be created by Marketing and passed on to the sales reps for follow up).

The second phase of the roadmap deals with implementing the Opportunity Management functionality. This second rollout is comprised of the entire sales force.

The third phase of the Acme Company roadmap tackles some of the customer service functionality required. During this phase, the Interaction Center WebClient is implemented with order entry capabilities.

This example has a few key points that you have to remember. The roadmap is a dynamic document — you must update it periodically based on the changing business needs and priorities. Start small, get one or two successes under your belt, and only then rally the troops to implement the big-ticket items, such as Opportunity Management or Order Entry.

Strategic vs. Tactical

There is a distinction to be made based on the type of project you are dealing with: tactical or strategic. A tactical project requires only a medium level of resources, and low visibility at the C-level suite might be acceptable (a typical example is adding some standalone functionality to an existing SAP CRM system). On the other hand, a strategic project requires the utmost visibility and support from the corporation’s management. The resources for such a project have to be in sync with the real business needs (i.e., scope).

The way your project is treated by the organization is critical for its success. For a better understanding on the differences between a strategic vs. tactical approach, consider a fairly straightforward CRM implementation — a Voice of the Customer (VOC) type of system. For the sake of simplicity, at this stage I won’t discuss the probable integration issues for such a system. In its simplest inception, the VOC system has to address these three requirements:

• Capture input from all customer touch points (e.g., Customer Service, Technical Support, Accounts Payable, Quality Control, Sales Force)
  
  
• Allow routing of the VOC cases to the proper owner and notification of the selected owner
  
  
• Classify the customer input by type (e.g., Complaint, Suggestion, Marketing Request)

Because this seems fairly straightforward, how would you treat this project? Would you consider it tactical or strategic in nature? This is a clear example of the iceberg principle — while you see 15% of the iceberg above the water, the remaining 85% is below the surface and invisible to the naked eye. Consider how the various departments will look at such a project and if this would be considered a tactical project only for the customer service department’s benefit. You could probably deliver such a project with off-the-shelf SAP CRM technology (Case Management) fairly quickly and relatively cheaply, assuming you have an SAP.com license.

Now, fast forward to the go-live date. Your new VOC system is up and running and all your customer service representatives are happy. Because this was perceived as a customer service-centric project (and hence a tactical one) without company management sponsorship, not all of the departments are necessarily on board to use the new system. Perhaps some of the users are inclined to give it a try because they took the optional online training and see some value for themselves or their respective departments. However, the remaining potential users will look at this system as just another IT tool they’ll have to input data into without getting anything of value.

I’ll present a hypothetical scenario: a customer complains the price on a certain invoice is wrong. The customer calls your company’s 800 number, and the agent on the phone documents the case as a complaint. The agent can assign the case to the proper owner (or department) — and she chooses to do so by routing the case to Jane in Accounts Payable (AP). Jane’s a great AP clerk, but she does not see a lot of value in the new VOC system, so she probably only glanced over the provided online training. She sees an email notification, but because she’s already busy and taking action on these VOC cases is not in her job description, she ignores the email notification. Now you have a customer that’s upset about the incorrect price charge and a case that’s not acted upon — and the invoice isn’t corrected. The customer will have to wait, and perhaps even call back, until the problem is finally resolved. Needless to say, this is a bad process.

Now I’ll show you another variation of the same example I just presented, but this one considers the VOC project as a strategic one. Everyone — regardless of department — has to use the system and document all interactions with the customer. There were clearly communicated response time requirements — such as a customer must always be issued a response for a complaint in less than two days.

The same VOC system is implemented, but the environment it is used in is different. All departments are mandated to use the new system, and they are explained the value in documenting all interactions with the customer. Everyone has been shown the value they can get out of the new system and how they and their respective departments can benefit. The exact same scenario, played again under these different circumstances, would end with Jane the AP clerk fixing and reissuing the invoice soon after receiving the case. She will also document the resolution in the case notes and close it down. While the customer might not be delighted to start with, he will definitely feel better with a speedy resolution of the problem.

Using this VOC system not only increases customer satisfaction, but also gives management access to significant customer interaction data. Interesting trending analysis will then be available.

As you now understand the difference between tactical and strategic, how can you ensure that your strategic projects are viewed as such by the entire organization? The project sponsorship is probably the prime factor in ensuring your project is perceived as strategic. The management of the company has made very clear this VOC project is one of strategic importance for the company via the project sponsor (someone in a leadership position in the business). So, who is this business leader? It cannot be the director of customer service or any other midlevel manager. You should also not attempt to do this project as an IT project. It has to be one of the top business managers of the company, such as a senior VP. The project sponsor will exhibit two key characteristics: be a high-ranking official of the company and be passionate about the project. Any other approach to fill this important role will lead to issues down the road — do not underestimate this critical success factor for your project.

End-User Adoption

Having a good end-user adoption rate means that your SAP CRM system is used by the vast majority of its intended user base. There have been quite a few SAP CRM projects that went live successfully, only to fade away soon after due to lack of adoption. It’s not enough for an SAP CRM project to be technically successful — the intended users must actually use the system. For example, take a system used for forecasting sales. In such a forecasting system, the sales reps would have to maintain their opportunities with reasonably correct data on which products would be sold and at what quantities.

Assume this system is used by the production planning department to stock the goods that are to be sold to customers. Only a minority of the sales reps are actually correctly maintaining their opportunities. What this means from a production planning perspective is that the forecast would consistently understate the quantity of products needed for your customers. The end result of such a scenario would be too many orders and too little product to fill those orders, which eventually would translate into a lot of unhappy customers. On the other hand, if the vast majority of the sales reps are maintaining the SAP CRM system, the resulting forecast would be quite accurate (for this example, I’m not considering the accuracy of the forecast received from each sales rep, but rather only the average). The production department would be able to produce very close to what the customers would end up ordering.

George Fratian

George Fratian is a CRM project manager with more than 11 years of experience in the SAP arena (CRM and R/3). The past five years were dedicated to various projects implementing mySAP CRM systems in different industries such as Oil & Gas, Health Care, and High Tech. He has designed and implemented complex mySAP CRM-based solutions for Fortune 20 companies in the areas of Internet Sales and Online Sales, Sales Force Automation, Case Management, and Interaction Center WebClient.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.