CRM Fundamentals

Marketing: Customers, Security, Service and More

Customers

Customer records are the heart of the CRM application, around which most other information revolves. These are broken into “account” or “company” records to represent organizations that you interact with, and “contact” or “individual” records to represent individuals.

Key customer functionality to look for includes the following:

• The ability to add fields to categorize customers in multiple ways—by sales territory, by market segment, or by industry

• The ability to track multiple types of organizations, either using the customer record or using other records, such as partners, vendors, and prospects

• The ability to create multiple, ad hoc relationships to link accounts and contacts in order to represent the multitude of important relationships that might exist

• The ability to easily track interactions with customers such as meetings, phone calls, e-mails, and faxes

Marketing

Marketing features are intended to help execute and track outbound marketing activity such as direct mail, e-mail blasts, and telesales call-downs. A critical factor is how well the marketing thread is persisted through to the sales area, to help tie revenues to marketing activities. This is a common challenge for marketing teams and one that CRM applications are well-suited to address.

Key marketing functionality to look for includes the following:

• The ability to manage suspect/prospect information independently from customers for qualification and marketing purposes

• The ability to develop lists using various criteria and then direct marketing activities against the lists

• The ability to organize marketing activities into campaigns for planning purposes

• The ability to execute direct e-mail campaigns in a robust way (for example, tracking e-mail opens, bounces, and forwards; using rich templates for e-mails; and managing the opt-in/opt-out process)

• The ability to tie sales and customer acquisition activity back to marketing efforts

Sales

The sales department is where CRM applications got their start (referred to as sales force automation [SFA] applications in the early days), and sales teams continue to be the primary driver for CRM initiatives. There are a number of motivations for bringing CRM applications and well-designed CRM processes to sales teams—the most popular include providing management with better visibility to sales activity and the sales pipeline, helping to support a structured sales methodology, and reducing administrative work and helping salespeople be more productive.

Key sales functionality to look for includes the following:

• The ability to manage sales opportunity information such as deal size, estimate close date, products/services being sold, and stage in the sales cycle

• The ability to define and manage a structured sales methodology

• The ability to create quotes for presentations to customers and prospects

• The ability to create a sales forecast for reporting to sales management

Service

The customer service features of CRM applications are intended to help organizations record customer issues and effectively manage them through to resolution. Service processes are often among the most studied and structured in an organization, because of their significant impact on the customer experience and the desire to control costs in a department that is not traditionally a profit center.

Additional benefits of managing service processes within the CRM application include the following:

• Service staff members are often a source of potential follow-on business within existing accounts—by having service employees working in the same application as sales, handoffs between the teams can be streamlined, and workflow automation can prevent dropped leads.

• Service issue data is a rich trove of information that can be used to improve and refine the organization’s products, services, and customer-facing processes. The easy linkage between service data and customer data allows for insight into the distribution of service-issue categories across customer segments.

Key service functionality to look for includes the following:

• The ability to manage and categorize service issues (often referred to as cases or trouble tickets). Information tracked for each issue may include the stage in the service process, issue type, related products/services, and issue owner.

• The ability to define and support multiple issue resolution processes for different categories of issues.

• The ability to support service queues to facilitate issue routing and resolution.

• The ability to deploy a self-service portal where customers can log in to create, update, and view service issues.

• An integrated wiki or other knowledge base tool to foster information sharing across the service department.

Security

Although some organizations configure their CRM applications in an “open” manner—where each user can see all information in the application—many need to be able to compartmentalize information. Common examples include sales information, sensitive customer information such as Social Security numbers or account numbers, or even compensation or commission information. A robust security model within your CRM application will give you the flexibility to manage a wide range of different security scenarios.

Key security model functionality to look for includes the following:

• The ability to secure information at both the entity level (for example, accounts, contacts, sales opportunities) and the individual field level (for example, Social Security number)

• The ability to bundle permissions into “roles” that can be assigned to users or groups to facilitate user management

• The ability to handle security exceptions—for when a user needs access to a certain record or set of records outside their current scope of access within the application

• Security that is pervasive throughout the application—applies to viewing information through the user interface, any search or querying tools, and reports and dashboards

Configuration and Customization

CRM applications always require configuration and customization to deliver an elegant user experience and to maximize the value they can provide to your organization. Each organization is different, with different types of customer information to record and different business processes to support with its CRM application. When discussing changes to the CRM application, we use the term configuration to describe changes that can be made using the application’s administrative tools and features, without programming, and customization to describe changing the application via programming. The extent and sophistication of a CRM application’s configuration abilities and customization flexibility will determine to what extent you can tailor the application to your present and future needs, as well as the level of effort this tailoring will require.

Key configuration and customization functionality to look for includes the following:

• Ability to extend the application data model without programming. This includes adding new fields to preexisting entities (such as “customer” and “sales opportunity”), as well as designing new entities. These new entities that you define should be fully formed, with the same capabilities as the preexisting entities.

• Ability to insert custom business logic via code into the system to change the way it behaves, typically around system events (for example, the creation of a new customer record or the reassignment of a sales opportunity).

• Ability for other applications to interact with the CRM application. Does an application programming interface (API) exist for the application? How robust is it?

Reporting

A large measure of the value of the CRM application is realized through the use of well-designed reports that provide business insight and enable informed decision making. For employees who do not interact with customers, the direct value of the CRM application may be exclusively that gained from CRM reports and dashboards. Don’t put too much stock in the out-of-box reports—they are typically too generic to be useful without customization—but rather focus on the report generation tools and the accessibility of the data.

Key reporting functionality to look for includes the following:

• User-focused tools that enable construction of basic reports and dashboards without programming.

• Open access to the data using other reporting tools via standard protocols (for example, ODBC), in a way that respects the application’s security model. For example, some applications allow data to be exported to Microsoft Excel for reporting and analysis.

-------------------

If we make the process of launching and managing a CRM program sound like a siege, this is only to make a small contribution toward reigning in the rampant marketing of the CRM vendors, who consistently send the dangerous message that if only you will purchase their application and install it, all will be right with your organization, and you will begin to reap the benefit of a business that is in tune with itself and its customers. CRM applications can have an amazing positive impact on your business, and they can help you transform into a nimble organization that delivers outstanding customer experiences and can turn on a dime to capitalize on new opportunities. But the application can’t do it for you—you have to “own” your CRM program and understand that you are responsible for its success. This is why we consider “reasonable expectations” a critical component of a successful CRM program—reasonable expectations around the effort required, the costs, the short-term outcomes, and the longer-term ones. 

Why a Phased Approach to Your CRM Program?

When you have developed your initial vision for your overall CRM program, it may be tempting to try to realize the entire scope with a single project. This appears to be the most direct and shortest path to achieving the vision. We strongly discourage this type of “big-bang” approach, where your organization attempts to move from “no CRM” to “full CRM vision” in a single project. In this section, we hope to convince you that a phased approach, whereby several smaller projects are chained together to progress toward the complete vision and grow the footprint of CRM, is a much more sensible approach and will increase the success of your program. Building internal momentum for one big push may seem easier, and rolling out the program to all employees at once seems simpler than coordinating multiple phases, but do not be fooled.

It Takes Too Long

The longer the duration of a business process and technology application project like CRM, the greater the likelihood of failure, because of a number of factors. Turnover on the project team saps the team of its institutional memory—decisions are rehashed and redebated as new team members join, further slowing project progress. The larger the project scope, the more stakeholders must be involved, demanding a voice in the decision making and resulting in a slower, committee-driven project. Fatigue saps the energy from the project sponsor and other executives, who grow weary of selling the benefits of a project to increasingly skeptical employees who grow to doubt that the program will ever launch. The longer the project duration, the more time elapses between the design of the CRM processes and application and their rollout. At the pace of business change today, the longer this time period, the further out of alignment the program will be with the reality on the ground and the needs of the employees when it actually launches.

In a phased approach, each project is smaller in scope and shorter in duration, with fewer objectives and stakeholders. Each project builds on the prior and expands the reach of CRM within your organization, addressing a new department or business process. We will introduce guidelines for how to break your program into phases to build your roadmap later in this chapter.

There Are No Opportunities to Incorporate Feedback

With a phased approach, there is the opportunity to do a post-project review after each project phase and incorporate lessons learned and successful practices into the next phase so that your project execution is theoretically improving with each phase as you refine your project methodology to best suit your organization. With the big bang, there are fewer opportunities for this type of learning, because each stage in the project is fundamentally executed a single time.

Pilots and the “Proof-of-Concept” Project

Pilots and “proof-of-concept” projects can be considered just another type of CRM project that should be fit into your roadmap as needed. These special projects serve a specific purpose—to validate a specific element (that is, process or technology tool) in a small-scale, low-risk way prior to a larger-scale project. The two terms are often used interchangeably, but in our lexicon they have distinct meanings.

A pilot refers to a complete project that delivers the changes planned for the entire organization to a small segment to get a preview of what the results will be for the entire organization. The project is complete in that the affected segment changes the way they conduct actual business; it is not a simulation or test. For example, before rolling out a new process and technology tool for collaborative customer proposal generation to 2,000 U.S.-based field sales personnel, an organization might choose instead to pilot it by rolling it out to the 100 salespeople in the Los Angeles office for a period of six months. This approach minimizes the organization’s risk—if the changes have a negative impact or otherwise fail to deliver on their goals, only 5 percent of the sales organization is affected. The downside is of course the delay; if it proves wildly successful, the organization has lost six months of benefit to the rest of the sales team via the pilot approach. Critical to a successful pilot is an up-front consideration of outcomes—what outcome will trigger an organization-wide rollout, and what will trigger rework or abandonment of the effort? How will these outcomes be measured, and by whom?

A proof-of-concept is a more limited project, generally intended to prove a technology tool before full development. In a proof-of-concept, no change is made to how the organization conducts its actual business; it is simply a research project to explore whether something can be done in some small way before attempting to do it in a large way. For example, imagine that a paper products company wants to outfit its field sales team with a mobile device that will allow them to initiate a variety of transactions in the company’s ERP application (for example, placing a new order, checking an order status, getting approval for a discount) from a customer’s location. The mobile device vendor assures the company that this can be done, but they have no experience integrating their device to the company’s ERP application, and they have a limited understanding of the company’s network security that would need to be navigated to allow remote transactions. Before embarking on a full design and development project to roll the device out to the global sales force, the company elects to conduct a proof-of-concept. The goal is to build a light sample application that can connect to the company’s ERP application from a remote location and retrieve an order status. This is a dramatically smaller project with limited design and development work (the application does not need to look good or be easy to use—no salespeople will ever see it, and it needs to support only a single type of transaction). But if successful, it proves that the vendor can navigate the company’s network security and interact with the ERP application. Proving these points eliminates much of the risk associated with the larger project. As with the pilot example, the trade-off for this risk mitigation is time and dollars—the full project is on hold while the proof-of-concept is delivered, and including a proof-of-concept project increases the overall cost of the initiative. As with the pilot, thoughtful consideration of what the goals of the poof-of-concept are, and what outcome constitutes “proof,” should precede the project.

Both pilots and proof-of-concept projects can be useful to control risk in your CRM program, but they have a schedule and cost impact that must be considered.

Understanding the Phases of a Project

Dozens of high-level methodologies exist and are commonly used for implementing technology applications. From the beginning, many organizations have a preference for a methodology, and frankly, most can be used or adapted for your CRM program. Based on our experience implementing CRM applications, we will provide some information on the most commonly used and successful methodologies and will recommend a process that ultimately takes the best from a number of approaches. This will provide you with something you can use as you implement the application in your organization.

The Software Development Life Cycle (SDLC)

The SDLC is a high-level process and set of associated tasks used for creating or altering systems. The methodologies outlined later in this chapter all utilize some parts of a classic SDLC process, so there will be an opportunity to leverage different pieces as you look for the best practices of each when working through your implementation. That said, they all tend to differ in how quickly you work through the various tasks, their flexibility when it comes to task completeness vs. moving on, and the level of detail they encourage you to track and utilize. The general components of a SDLC are as follows:

Plan/analyze: The plan/analyze activity, often also referred to as the envisioning stage, is the place where the goals of the project are outlined, the project ROI is defined, and the roles and responsibilities are identified for the phase of the implementation. This activity is also where the design of the application is completed and requirements are gathered, vetted, reviewed with the team, and finalized in some form. This design can take a number of approaches, some variants of which will be identified in the upcoming text, but ultimately, at the end of this phase, the requirements for the implementation phase have been identified and locked in.

Implementation: The implementation activity focuses on building any in-scope items identified during the plan/analyze stage of the implementation. During this activity of the SDLC, items are also unit tested, and bugs are fixed as necessary. Depending on the design approach you choose to take, the build phase may require more or less time, but ultimately, the development of the application will be complete when this phase ends. A number of very critical components of the implementation, including the various types of testing, need to be completed at this point as well. We will focus more on the various testing types later in this chapter.

Deploy and support: Deployment activities focus on rolling out the application to end users and supporting it after release. It is during this piece of the implementation that both end user and administrator training occur. The application is then rolled out to end users and appropriately supported following deployment.

Much of Chapter 6 will focus on providing additional detail on the previous items. Specifics about design, development, testing, training, and deployment will be outlined. For this chapter, now that we have identified the high-level activities to be completed as part of an implementation, we will provide additional detail on the various ways to implement these activities.

Waterfall Methodology

One of the most common methodologies used during technology and, more specifically, CRM implementations is the Waterfall methodology. This methodology is designed as a series of consecutive steps, one following the other, where the stages flow much like a waterfall. Figure 5-2 shows a simple, graphical example of a Waterfall methodology.

Of primary importance to the Waterfall methodology is sequence. Generally, one step must be 100 percent complete prior to taking on the next. Additionally, this methodology is very heavily focused on documentation. The rigid structure of the Waterfall methodology often causes problems for implementation teams. A CRM project rarely moves in a straight line, so an ability to be creative and adapt project schedules to meet the team’s needs is important. The heavy focus on documentation also puts a significant burden on the project team. Stakeholders are often stretched thin with their “day jobs” to begin with, so adding the weight of detailed documentation frequently causes all their work to suffer.

Scrum Methodology

Another common methodology is Scrum. The primary premise of this methodology is short, fixed-length design and development cycles. Scrum cycles typically range from two to four weeks and include very fixed scope. These cycles are often referred to as sprints. Each sprint begins with a discussion where the collected list of desired features is reviewed by the project team. The team then identifies the features that can successfully be developed within the two- to four-week sprint period, and then the work begins.

One key premise to the Scrum methodology is that once a sprint has been identified, it cannot be changed. That said, another key principle is flexibility. Because sprints are short in duration, the user community can more easily change their mind or approach to a requirement and can implement that change in a subsequent sprint. Items identified as features for the next sprint are called the sprint backlog.

Even though they’re short, many of the activities identified in the SDLC are used, albeit in an abbreviated fashion. A brief design and development phase is followed by a demonstration of the new functionality. This demonstration replaces the more detailed training activity that occurs in longer projects. By nature, the project teams using the Scrum methodology meet regularly and briefly cover any items discussed in the plan/analyze phases through the life of a sprint. As an organization, Figure 5-3 shows how you might view a project that includes a number of sprints.

Iterative Development Methodology

Both of the methodologies outlined thus far have some limitations when associated with CRM implementations. Based on our experience, one of the biggest places where implementations can fail is a lack of user buy-in. One of the challenges with the Waterfall methodology is that the need to complete one stage before beginning the next requires the project team to develop a very detailed design document. This document is developed with input from the end users and reviewed prior to the beginning of development. Ultimately, the next time the user community will see the application is during user acceptance testing, so this approach opens the door for users to be surprised or disappointed with some of the assumptions or trade-offs made.

Many CRM implementations include enough functionality that short design sessions and quick development cycles associated with the Scrum approach make meeting users’ expectations for an initial implementation difficult. Even the smallest of CRM implementations may take a number of weeks, with larger implementations taking 6 to 12 months or more. Additionally, one key premise of Scrum projects is a brief demonstration of new functionality to users instead of a full user training cycle. With most initial implementations, spending a significant amount of time educating users about the application, including where it can help them be more efficient in their jobs, is important.

Because of these and other limitations associated with many methodologies, we often employ a derivative of the iterative development methodology on our projects. This methodology is often referred to as the iterative and incremental development methodology. With this methodology, the idea is to loop your application through a repetitive (iterative) design process over a shorter period of time (incremental). Visually, this methodology looks very similar to the Waterfall methodology with two key differences:

• There is an overlap between stages when using the iterative development methodology. Much of the work to be completed in a particular stage can be started prior to the end of the previous stage.

• During the design phase, the iterative approach provides the implementation team with a mechanism to gather requirements, build or configure pieces of the application, and then repeat the process. The implementation team can repeat these iterations as many times as necessary to get the appropriate amount of feedback from the users.

Figure 5-4 shows how the iterative and incremental development methodology differs from the Waterfall methodology identified earlier in this chapter.

As you can see from Figure 5-4, the stages overlap, allowing tasks from one stage to begin before another is completed. The design stage of this methodology is typically longer than others because of the iterations. Additionally, you may typically see a shorter pure development stage because some development and configuration is being completed during the design stage. The iterative process should look like Figure 5-5.

The iterative process should involve getting an application in front of end users quickly. Doing this will ensure the following:

• User buy-in: Engaging users through the application will allow them to become more invested in the end result. Additionally, because of the extended design timeline, the momentum of the project should continue through the end.

• Accurate requirement capture: The iterative process provides users and the implementation team with the opportunity to review and change the requirements multiple times prior to them being locked down. Instead of building a design document and hoping that it accurately captures the requirements, this approach allows users to see the end result even before that end result is completely defined.

• Design and build consistency: Having these two stages overlap so much provides additional consistency and checkpoints throughout the development process.

Project Communication

Effectively communicating throughout your project will be a significant factor in its ultimate success. More importantly, how and when you communicate to the collective project team will greatly influence their perception of the project and outcomes. During the planning phase of your project, ensure that you put thought into the various communication medium, communication frequency, and messaging that you will use throughout your project.

Portals as Project Management Tools

Many companies today utilize portal technologies as tools to assist with managing their projects. Much like a status report, a portal can be a tool to accommodate various stakeholder groups and can assist with ensuring appropriate tracking of documents and other information. The following are some specific use cases for portals during your project:

• Status reporting: Depending on the size and scope of your project, leveraging a portal as the tool to present your status reports could make viewing and collaboration easier. Within most portals, you have an opportunity to break out summary and detailed information into different sections. This essentially accomplishes the same thing as breaking the status report into distinct sections but saves the project manager from sending an e-mail that may get lost in the recipient’s inbox.

• Document management: With projects of all sizes, managing, exchanging, and updating documents can be a challenging task. Using a portal technology with document management capabilities can simplify this process. Most of these technologies have the capability to manage check-in/checkout processes, outline changes to a document, and supply version control features to users.

• General information sharing: As a project’s complexity grows, typically so do the number of resources involved. As the resource list grows to include internal and external (vendor) resources, having a tool to allow collaboration becomes important.

• Logging: If your project has any complexity, you are likely to experience some risk during the life of your implementation. A status report can be used to highlight this risk, provide notes or comments on mitigation steps that are being taken, and provide a history of issues encountered and steps taken.

Tracking “Parking Lot” Items

Another item to plan for prior to executing your initial implementation phase is the tracking and managing of scope items deemed important but not part of the current phase of the project. Another common mistake from implementation teams revolves around including additional scope in a project. Once the project begins, the user community can place a significant amount of pressure on the project manager(s) to include new items into the project scope. Although there are absolutely times where this inclusion is merited, the tracking and triaging of these items will enable the project manager and steering committee to make educated decisions about if and how to change scope when requested. Figure 5-11 shows an example of a simple yet effective spreadsheet used for tracking these items.

1. Topic and description: Although extremely basic, the topic and description should be used to capture a high-level, and slightly more detailed, overview of the scope change being reflected. This spreadsheet will be used by the user community at large, so providing an understandable description will head off any questions from users.

2. Priority and subpriority: Including both a priority and subpriority allows the project steering committee to get very granular when evaluating new scope requests. Should additional time or budget become available, this detailed ranking of requested scope items will allow a carefully thought out decision to be made around which scope to include.

3. Owner: This is yet another simple piece of information to track related to a scope item. That said, it is also very important. The owner of a requested parking lot item will ultimately be responsible for driving additional requirements necessary to make an informed decision about whether to include this scope in the project. Typically, this person is also responsible for initially prioritizing and then presenting this item to the steering committee for review.

4. Date and resolution: As we mentioned earlier in this section, the user community at large will likely utilize this spreadsheet to track the progress of their requests. Providing them with updated entry dates and status will allow them to feel comfortable that the request is moving forward.

The Challenges with Over-customization

Very similar to the issues caused by employing a big-bang approach with the initial phase of your implementation, it is easy for the project team to find themselves in a situation where they over-customize the application in an attempt to meet users’ requirements. Over-customization is something that is more likely to happen with larger, multifunctional implementations. As an example, when two sales teams with drastically different interests and sales processes utilize the same implementation, there’s the potential to add too many fields, customizations, and automations to the implementation. Ultimately, the addition of too many things into the application has the potential to cause the following:

• User confusion: The ability for users to quickly ramp up on the application during training and post-release will make or break the success of your initial implementation. If there are too many fields, or if users receive a significant number of e-mails or tasks generated by the application, they’re likely to be confused and abandon the implementation.

• Unnecessary process impacts: Very similar to the previous bullet, if the new features of the application require users to jump through process hoops that are unfamiliar to them, they may struggle to adopt the application.

• Additional support costs: In situations where over-customization has occurred, users either will struggle with the tool or will require “emergency” changes to allow them to feel more comfortable with the solution developed. In either of these cases, support from an internal or vendor team will be necessary to keep the application moving forward.

Over-customization is an item that can be controlled by the collective implementation team. Leveraging an iterative approach with application reviews to ensure users are comfortable with how the application is being built will prevent a surprise later. Additionally, using classic scope management tools like the status report and project charter, combined with managing parking lot items, will keep the focus of the initial implementation on items that add the most value to the user community.

Issue Management

Although we may begin to sound repetitive, being prepared to manage issues is yet another important facet of planning the project. Much like parking lot items and status reports, having issues be transparent to users will go a long way toward allowing them to trust the implementation team. In addition to this potential value, managing issues is about accountability and risk.

To successfully manage issues throughout the life of a project, having a mechanism to track them, however simple, is important. This tool will also allow the core project team to manage the ownership of those issues to ensure the proper follow-up and triage by folks on the project team. Figure 5-13 shows one example of a simple yet effective template you can use to track issues.

Common Project Issues and How to Avoid Them

Now that we have provided you with an overview of the various processes and tools that can be used to help you implement your CRM application, we wanted to outline a few of the classic project issues that arise with CRM implementations. We will provide a few of the symptoms or causes of these issues and a bit of information on steps you can take to avoid them.

Over-scoping

At various points in this book, we talk about using a phased or big-bang approach to CRM. Over-scoping is another way of articulating the same challenge. Allowing too much scope, or scope that collectively requires too much change, into your CRM implementation will provide significant challenges to you as you roll out the first version of your CRM application. It isn’t just the volume of scope that defines whether a solution is over-scoped but the complexity of the scope as well. If you include numerous integrations, multiple system replacements, or other complex items, your user community could become overwhelmed by the change.

Focusing on small, manageable deployments is the easiest way to mitigate the risk of over-scoping. If you can, break the first phase of the implementation into a small, meaningful set of scope that provides distinct value to the end user community. Once you’ve had a successful phase, finding more time, budget, and success should be a straightforward process. If you do need to do a large implementation as part of the first phase, critically review the scope items to ensure that no one user group is over burdened by the change. You can also devote extra time to training and user support to help alleviate any of the extra risk added by a larger scope volume.

Overly Complicated Design

Whether you are simply designing the account and contact entities or are focused on a broad set of custom entities and attributes in your CRM application, trying to make them all things to all people can quickly cause conflict when it comes to the form layout and usability. This conflict exists whether looking at CRM forms or the complexity of integrations and custom items in your CRM program. Building too much up front or not carefully managing the expectations of users can cause the design and, ultimately, the implementation of your CRM system to become too complex and will cause issues with user adoption.

We often hear our customers and other consultants talk about using out-of-the-box functionality whenever it is available. This is absolutely one place to start when looking to avoid an overly complicated design of your CRM application. In addition to focusing on native CRM features, having someone involved in the project who can objectively look at the various requests for customization or automation and provide guidance on what to build initially will help ensure your design both meets users’ needs and remains as uncomplicated as possible.

Software-Driven Projects

A common mistake most organizations make is allowing the features available in various CRM applications to drive the overall implementation. Whether they change an existing, working process to fit within the new CRM tool or implement a feature just because it is available in the tool, this immediately puts the adoption of the tool at risk. Any time users are required to change a process for the sake of technology, they are more likely to rebel against the application and look for workarounds to the new application. Additionally, this approach often leads to over-scoping, which will cause many of the same issues.

With the technology available today, virtually anything can be customized or built into your CRM application. Focus on using the tools to make the application fit your organization’s desired processes. We recognize that endlessly building things into your CRM tool is both costly and time-consuming, so it may be important to prioritize items that do the most to facilitate processes, but eventually, with the right focus and continued dedication, you will eventually implement all the necessary functionality to meet all the process requirements.

Lack of Executive Support

At virtually all points throughout your project, having the appropriate level of executive support is crucial to finding the right vendor (if appropriate), helping set the implementation team’s priorities, and guiding the overall project. Following the initial deployment, executive support is critical to helping drive user adoption for the solution and ensuring any issues that arise are both communicated appropriately and dealt with in the appropriate way. If at any point the support from the executive team, or even just the level of communication, begins to wane, this will represent a risk to your project that should be dealt with quickly.

Managing any issues that arise around the level or amount of executive support is generally pretty straightforward. Fortunately, most executives respond when presented with a risk that will cost them either money or trust, so simply raising the issue will often raise the level of participation. If that alone does not work, look for opportunities to help them with things like communication by drafting project e-mails. Finally, ensuring that they have all the necessary information at hand when talking about the value of CRM or are addressing any issues will make them much more likely to participate heavily in the process.

Managing Differing Priorities

Whether the conflict is focused on the CRM implementation or a conflict pitting CRM priorities against something unrelated, being able to manage the varying priorities of your stakeholders on the project will be key to getting the appropriate level of participation from them. If individuals on the project team have differing project priorities, dealing with them from the very beginning of the project can be a big win.

Tools such as the project charter, project status discussion, and even design documents can be used to bring the team together and raise any important issues. If the conflict exists between CRM priorities and those associated with another organizational initiative, your executive sponsor and project steering committee are going to be the best mechanisms for you to resolve any problems. The larger your organization is, the more likely these types of conflicts are to occur. If necessary, plan to build some additional time into your project plan to account for small shifts in priorities throughout the project.

Application Adoption

We discussed application adoption earlier in this chapter. With that information in mind, all of the items outlined in this section of the chapter can contribute to a lack of application adoption. Having priorities that spread users too thin, over-scoping, a perception of lukewarm executive support, and other items should all be avoided where possible to allow users to adjust to the new application. Issues with application adoption could derail both your initial implementation and your ability to get support (and funding).

Addressing concerns quickly is important. Providing additional training, support time, and resources to your team throughout the process will enable the implementation to go well and should position your team well for any future phases.

Change Control Process

The change control process is a continual process that helps organizations make changes and enhancements to their CRM program. Figure 7-4 shows how the process works.