3 - Building a CRM Roadmap
It's a general principle that a well-considered, thoughtful plan is more likely than a haphazard an uncoordinated effort - and the latter seem to be more characteristic of situations in which a firm buys into a popular technology without having a clear concept of what it wishes to accomplish or any semblance of a plan.
Using a Phased Approach
One of the problems of implementing a sizable project is the desire to achieve the full vision as quickly as possible, taking on the entire scope in a single project. The author discourages the single-bound approach to a CRM project, as moving from "nothing" to "everything" is a massive and overwhelming effort.
The larger the project, the greater the likelihood of failure: impatience grows while enthusiasm fades, there is greater turnover over a longer period of time, decisions are rehashed and re-debated as new team members join, the more attractive it is to those who wish to latch onto it , the team becomes fatigued, and the business changes its practices in the interim.
While there is less drama to doing a series of smaller projects rather than one big one, it is easier to tackle a big job in small pieces, and stands a better chance of getting done and delivering value - and real results are ultimately more compelling that promises of big things to come.
The phased approach enables those involved to achieve the goals quickly, is less attractive a target for budgetary cuts of political reasons, and has less chance of people hopping off of and onto the project as it progresses. It also enables the team to observe and learn - to do a postmortem at the end of each small projects to discover lessons-learned and best practices that will improve later efforts.
Building Your Initial Roadmap
Plans and situations change, which is important to acknowledge as you approach the task of developing a roadmap for a CRM program, or any sizable undertaking. It is unlikely that you will execute on a long-term effort exactly as planned - though this is not an excuse for neglecting to plan at all, being too rigid about a plan, such that there is no ability to adapt and change when a valid need arises, can be almost as damaging.
The first step in planning a journey is to know the starting point. Assess your current situation, specifically in terms of:
- Processes that involve or affect the customer. Gather information about your current business processes that are already in place. Chances are the mere task of analysis will identify inconsistencies, redundancies, and conflicts - they can be addressed, but should not take focus away from the primary goal of finding ways in which CRM initiatives can improve each process. For now, accept the as-is such as it is.
- Information systems that manage customer data. Create a catalogue of all the applications and systems that are used to manage data about the customers and the firm's interaction with them. Interview the users of these applications to understand what value they currently provide to the organization. Again, you will likely discover a number of problems that should be addressed.
- Find pain points. Interview the employees on customer-facing teams with an ear for the things that frustrate them. People seldom complain without a cause, and with a little investigation, the underlying problem can be identified, and it may be something CRM can alleviate.
- Strategic goals. The organization's strategic goals, those that have a horizon of five years or more, may also be a source of initiatives for the roadmap - or can be used as justification for pursuing certain initiatives. Consider not only what is in line with the goals, but what you might be considering that is not in line - such as supporting a sales channel that is becoming less relevant or being phased out completely.
- Technology issues. In many firms , the IT department maintains a separate roadmap for its own systems development - upgrading or replacing core business systems in coming years. CRM depends on integration with these system, so it is necessary to consider upcoming changes to the infrastructure.
- Red Flags. Early detection of issues that may endanger the success of your program is necessary to formulating plans to neutralize or avoid them. Some examples of red flags include: weak executive buy-in, limited IT resources, and weak business analysis skills.
The next step is to split the long-term vision into smaller projects and sequence them against a calendar for implementation. In some instances there will be hard dependencies (one task must be done before another can be started), but in many instances, the order in which projects are conducted is largely arbitrary, and there are no "rules" to guide you. However, there are some considerations:
- Business impact. The vision for CRM will likely have greater impact on some parts of the business than others, and for which a "quick win" - solving a significant problem or taking advantage of a significant opportunity that proves the value of CRM by virtue of its impact on morale or the bottom line.
- By Geography. Organizations that have multiple regions or divisions may wish to implement the system in one area at a time, as a method of easing into a change that will impact the entire organization. The "good news" of success in one region can stimulate interest in others.
- By Process. CRM efforts related to a specific set of tasks (order-taking, fulfillment, shipping) can be done as a method of gradual implementation. Generally, processes that are seen as difficult or clumsy can be prioritized, as employees will be less reluctant to try something new if the current way of doing business is a pain point.
- By Duration. You may wish to consider the pace of implementation according to the business cycle (if fall is a busy season and spring is light, plan a long effort that begins in summer and ends in spring to avoid launching something new in a chaotic time) or to deliver a burst of functions quickly to build enthusiasm before taking on longer projects that may require a more sustained effort.
There is an aside on the difference between a pilot project and a proof-of-concept project. A pilot refers to a project that delivers functionality to a small group of individuals in order to get a preview of what the results will be like when it is rolled out to the entire organization. It is not a simulation or a test, but the beginning of a distribution that will very likely go through, and the pilot merely identifies issues so plans can be made to address them as the project goes forward. A proof-of-concept, meanwhile, is an project to determine if a proposal actually has value - and experiment to see what happens, if an idea has legs. The source of overlap is that if a pilot performs abominably, the full release may be cancelled; and if a proof-of-concept performs well, there will be pressure to make it more widely available sooner rather than later.
The next step is to "line up the people." The effort required to launch a new initiative, and to sustain its adoption so that it becomes a standard way of doing business, is considerable and you will need the support of key personnel. You should first identify them (often, the leads of the departments that will be impacted) and plan an individual conversation with each to determine two key factors:
- Bandwidth. Does the department have a clear understanding of what the CRM initiative is going to ask of them? Can it supply sufficient time from the right people in order to make the project successful? Does it have the capacity to participate fully?
- Buy-In. What is the existing level of enthusiasm for the CRM program and its benefits? Some will be hostile toward any prospect of change, others will be more eager to adopt, based on both practical and psychological factors. It may be wiser to deal with enthusiastic parties earlier, and leverage success stories to overcome reluctance or resistance of others who seem less open to the idea.
(EN: The author provides a lengthy "sample roadmap exercise" that follows the steps above in a fictional company. It's actually rather well-done, showing not only the rosiest of circumstances, but dealing with some of the rough patches. However, the narrative adds nothing to what has been discussed above, so I'm skipping it.)
Developing a Roadmap Midstream
If there is already a haphazard start for CRM technology at a firm, it may be necessary to begin developing one in mid-stream. Or if a roadmap has been established, it is also worthwhile to periodically revisit the planning process to determine if it should be adjusted.
The same process outlined above can be followed. You might be able to use some information from previous planning efforts to assemble a partial roadmap rather than starting from scratch, though it's questionable whether they are (still) accurate and valid.
There is also the necessary step of gathering feedback on the progress to date - as CRM has gained a reputation that can either be built upon or must be salvaged as you move forward.