Chapter 1, Planning Ahead
One of the most difficult steps of any CRM project is figuring out how to prioritize all of the necessary requirements. Get tips for organizing CRM project documents and prioritizing CRM project requirements when taking on a Salesforce.com SFA or CRM project in this chapter excerpt.
Planning Ahead, Chapter 1
Table of contents:
Beginning a Salesforce.com CRM or SFA project
Managing CRM project requirements
Creating a Salesforce.com CRM business case
Developing a CRM implementation schedule
Managing CRM project requirements
Organizing and Publishing Project Documents
Even before the project begins, best practices call for storing, publishing, and organizing the project's documents online. Put them in an intuitive hierarchy, with all the project-related documents in one place that is scanned by an internal search engine or a desktop index (such as Google's free desktop search or X1's indexer) and is backed up regularly.
You can store these documents in a shared folder on a file server, but even better is to have them in an intranet site. Best of all would be a wiki that's accessible to all team members (including contractors). Your top-level wiki "article" should include pointers to the project schedule, the current phase's goals and nongoals, project personnel, news, discussion forums, blogs, and user tips on the system. The wiki should also provide a hierarchical library that includes all of the requirements documents, discussions, rationales for priority calls, and the project requirements phasing spreadsheet.
You should also put a short document into SFDC's Documents section describing how to get to the file server or wiki. Promoting what's there will allow any interested user or project team member to quickly become better informed.
It's usually best that these documents be editable Word files, with change tracking turned on. For Excel files, the first page of the spreadsheet should include a revision history indicating who changed what and when. The files should be downloadable by any authorized user, but should be updatable only by sending the changes through the project manager. In this way, the project manager can filter and prioritize input and manage the evolution of the requirements and other documents (which inevitably change throughout the project).
Documents should never be deleted. Obsolete documents should be marked as such and moved to an archive directory.
For certain kinds of files, it's useful to leverage the shared editing and shared access of Google Docs. Although the files have to be much simpler (no macros or heavy formatting), Google doc sharing can improve collaboration in a distributed implementation team. This is particularly true for status documents, priority lists, or other highly collaborative content. SFDC has recently created an integration with Google docs that makes this option even more tempting.
One of the toughest tasks throughout the life of the project will be understanding the ramifications of requirements and making priority calls among them. With a system of any size, some requirements will have to be delayed or may even have to be abandoned as too expensive. Making these decisions can get interesting when interdependencies among the requirements exist, and things get even juicier when political overtones and competition among the requirement sponsors complicate matters.
Although this complexity sounds scary, there's a counterbalance. The overriding principle of prioritization for any SFA/CRM project is that it doesn't matter how many requirements you've delivered on if the users aren't adopting the system in droves. This is because the value of an SFA/CRM system—to sales, marketing, support, and executives—grows in proportion to the amount and quality of data the system holds. Make priority calls that cause users to get quality data in the system sooner and that persuade users to get on the system more often . . . and the rest will follow. Instill this overriding principle in the project sponsors as much as you can so everyone pulls in the right direction.
One way to guide prioritization discussions is to use the short list of the specific business problems that the executives defined earlier in this chapter. These specific improvements should be specific, unambiguous, and quantified—"reduce customer support response times by 20%," not "improve brand value." Estimate how the major features will affect these business goals, and from that calculate the return on investment (ROI) for the feature: lowering of costs, increasing revenues, or both. This overview page will help keep things in perspective as you try to make priority calls.
Like all complex decisions, the tough calls will be made in meetings where there is insufficient information. Your requirements summary spreadsheet is the tool the team will use to make those tradeoffs and priority calls. The goal of the project leader is to channel the discussions during these meetings down paths that are rational: all of the choices are achievable, and the final choice optimizes ROI.
Appendix A describes several tools that can be used to prioritize requirements. Give at least one of them a try to find out which tool is most natural for your team and produces the most credible priority rankings.
The two groups that usually get the highest weight in the prioritization are sales representatives and executives. Things that are of direct, immediate benefit to them are assigned a lot of points. The specific points you give to other departments and user types are up to you, but an SFA implementation team forgets "who's the boss" at their peril.
There isn't a universal formula for prioritizing requirements: too much depends on the specifics of your company. For example, should the requirements from highly sophisticated users (as identified in Chapter 5's SFA Maturity Model) be prioritized higher than others (because those users can gain the most) or lower than others (because those users will be better able to cope with an incomplete feature set)? The answer to this question inevitably depends on your company and its management style.
You'll want to carefully plan out who will start using the system when, as the timing affects priorities. Put simply, the timing and order in which you deliver SFDC functionality and extensions can have a big impact on the total project cost and schedule. Some functional areas go together very easily; others can involve a lot of controversy, meetings, and rework.
Almost always, the revenue-focused business processes conducted at headquarters are implemented first. Later, other headquarters processes are brought online. Usually, business processes done in the field happen a bit later.
You might wonder why the executive suite and other high-priority roles in the company seem to come so late to the system. Why aren't their requirements satisfied first? Chapters 3 and 4 answer that question: the quality, completeness, and relevance of the data in the system just aren't good enough early on. Any reports or dashboards an executive wants won't be reliable, and they could even provide misleading information that would lower the credibility of the system. It's a big mistake to bet the farm on SFDC data assets before they are ripe.
No matter what the order selected, use the ordering to help prioritize requirements. Requirements coming from teams that will be coming on board early should be treated as having a higher priority (so they get done early).
A key issue in prioritizing requirements is the "squeaky wheel" phenomenon, where a noisy or politically powerful proponent causes great emphasis to be placed on a requirement that isn't really critical. All too often, a significant proportion of the effort in large projects is devoted to requirements that are "nice to haves" but that ultimately waste time and effort. Consequently the highest leverage thing a project leader or business analyst can do is identify and deprioritize the uncritical. While avoiding confrontation, smoke out dubious requirements using gambits like these:
Avoiding Happy Ears
Whenever a new system is being developed and people are interviewed about what they need, users start to hear hints about how things will work. Nearly everyone will assume that if they've heard about an issue, it's going to be solved by the new system. They'll even extrapolate, imagining all the wonderful new features that will become available to make their job easier. It's human nature to be optimistic, and that goes double for sales and marketing folks. But this "happy ears" phenomenon leads to spiraling expectations and scope creep that can kill a project.
Project leaders and especially project sponsors must continuously push to lower these expectations, even if they yet haven't seen overt signs of happy ears. The project goals must be simple—even minimalist—for the first phases, and "great ideas" must be explicitly pushed off in time. Even when things are going okay, undersell and be tentative about making the schedule. Even if the team has a way of delivering "something great," consider delaying it (ironically, see "The Art of the Quick Win" later in this chapter). When you do deliver this great thing, do not publicize it until it's delivered, so that you can provide pleasant surprises to users.
In prioritizing and trading off requirements, the project leader will need a set of executive sponsors who can act as champions for political and resource issues. For SFDC project success, the champions must include the VP of Sales, but usually include the VP of Marketing, the CFO, or perhaps even the CEO. These key supporters cannot afford the time needed to participate in the project, so they'll need to deputize a senior person on their staff to be a regular participant on the SFDC implementation team. The project leader should form a management council of these deputies to make priority calls, policy decisions, and tradeoffs. For simplicity of voting, the team needs to be small and contain an odd number of people (including the product manager). A small management council would include representative from the Sales and Marketing departments, plus the project leader. A larger council might add representatives from the Finance, Customer Care, International Operations, Professional Services, Channel Operations, and Business Analytics departments. This council will need to have brief meetings on a weekly basis, and it should devote a significant amount of time to analyzing business processes. Because a key factor in ensuring project success will be the availability of the right people for this team, get their (and their bosses') commitments early.
The challenge for the project leader is to keep one (and only one) priority list that encompasses everyone's needs, while clearly limiting the number of items that are "must do's" for each phase. Even so, maintaining a consistent, clear, tightly enforced requirements priority list is an invaluable tool for the project leader, and its existence will help fend off countless arguments during the project.
When Requirements Should Bend
It is common for requirements to be stated as absolutes, with intricate detail being provided about the way things must be done. But these "requirements" are often an interpretation of a business need, or an executive's preference, or even a legal regulation. Sometimes, the literal requirement is a poor interpretation of the underlying business need. It's important to be as creative as possible in requirements statements so that you don't over-specify or get locked into one particular approach. Identify alternatives and different ways of achieving the underlying goal.
For example, the Finance department may have an edict that an order cannot be shipped without a manual approval. So the requirement is stated as a mandatory human approval cycle. But if the approval cycle is there only to apply a set of strict rules, maybe the manual approval cycle isn't the real requirement. By restating the requirement as "no shipment will be made without applying the following rules," it becomes possible to have a fully automated approval, saving time and cost on every order.
Look for opportunities to restate "requirements" that are over-specified or arbitrarily complex. Requirements should be statements of business goals and criteria, rather than strict stepby- step procedures.
In some cases, the best path forward is to change the business process, rather than investing in automation of a silly or obsolete practice. In particular, look for opportunities to make things better by making subtle changes to the sales and marketing processes. Some of the most doctrinaire SFA/CRM requirements miss key opportunities for leverage. The SFA/CRM system will give sales reps and managers information and tools they never had before. Because the whole point of the system is to make it easier for the reps to make their numbers, why not take the blinders off? For example, better qualification of leads can mean fewer pointless sales calls and shorter sales cycles. Likewise, marketing personnel should be encouraged to think outside the box, looking for new ways to plan campaigns and execute events. Of course, you'll need to get the executives' approval before you formally recommend process changes or restate the requirement, but it's well worth the effort.
Bending and restating requirements in this way can make the system easier to implement, easier to use, and more beneficial to the business over time. Knowing Your Boundaries
One of the most important issues in requirements setting is determining the "edges" of the system—that is, the boundaries beyond which users must log in to a different system if they want to do something. All users would like the system to encompass all of the things they need to access for their particular jobs, but it's impractical to deliver a single system that covers every business function for every employee.
When you first install SFDC, it has the following functional boundaries:
For a detailed view of business systems that touch on SFDC, see Figure 1-3. As shown in the diagram, several add-on products may be tightly integrated with SFDC to improve its functional coverage (see Chapter 7 for a discussion of these products). These extensions and external products are a huge strength of SFDC, because they allow the core system to be simple and easy to use, yet flexible and scalable enough to handle much broader requirements. Further, SFDC has a very open and well-documented set of external interfaces, presented as Web services. These "SOAP APIs" allow programmers to connect, integrate, and extend SFDC to almost anything.
Even though you could integrate SFDC with any external system, it's easy to overshoot the mark by trying to do too much in the initial implementation. In evaluating and prioritizing requirements, it's important to identify when a requirement crosses over into an external system. Any such requirement is inherently more complex and risky, so it should be assigned a lower priority than requirements that are entirely within SFDC's native functionality. Read the section on integration in Chapter 7 before you deal with any requirements for integration.
Thanks to the modularity of the SFDC architecture, almost all internal functions can be turned on in phases at the time of your choosing. For example, turning on the Campaigns or Forecasting function can be done the day you bring up the system or, alternatively, months later without involving significant rework. Many external add-ons act in the same way, allowing a very flexible deployment schedule. However, some of the more sophisticated add-ons (such as Eloqua marketing automation or Intacct accounting) will involve significant changes to your data, the user interface, and user behaviors. Consequently, the timing and sequence of deploying the more complex and expensive add-ons cannot be taken lightly.
FIGURE 1-3 SFDC and the Application Landscape
When Other Problems Must Be Solved First
In large organizations, the political drivers for installing or replacing the existing SFA/CRM system will be executive visibility, customer reporting, or uneven execution of business processes. Unfortunately, merely upgrading to SFDC will not help in many of these situations. In large organizations, other problems need to be solved before the new system will function properly, let alone resolve any deep issues.
The project manager should analyze the requirements and problem statements to understand which of them are actually caused by bad data, disconnected systems, unclear business rules, inconsistent business processes, and other "environmental" or infrastructure issues. These problems are typically scattered across several databases or applications, and fixing them will be a prerequisite to any successful SFDC deployment.
If you discover this situation, it is important to get a project team started on analyzing and remedying those external problems even before your SFDC work starts. That project team should be chartered to work with your SFDC team, but typically it should be managed separately. If this team is chartered to work under the SFDC team, make sure that its focus doesn't become too broad (e.g., "rework this entire outside system") or distract the main SFDC implementation team.
As with all requirements, the extension of SFDC via add-ons and integration with other systems should be prioritized with a keen eye toward schedule and risk. Even though basic integration is of the "plug and play" variety, the interaction among systems and databases can cause subtle data corruption problems that won't discovered for several weeks. Consequently, it is usually a good idea to deploy basic SFDC functionality without external integration, get the users comfortable using it, and get some real data flowing through the system (even if only manually) in the early weeks. Later, new functional add-ons and integrations can be deployed on top of a stable baseline system, and users can gradually become used to the new features as the system expands. External integrations (particularly with complex systems such as accounting, ERP, and marketing automation) should be started early for testing purposes, but not turned on for full two-way data transfer until later phases.
Appendix B provides example requirements for both a small company and a large company. Of course, every company's needs and priorities will be different, but the examples show the level of detail that you will need (not much at this stage) and the kind of interdepartmental prioritization you'll need to think about when preparing your company's list of requirements.
The SFDC system will almost certainly be implemented over several quarters, with only the first two phases as "hard priorities." Later requirements will be reordered depending on perceived business priority after initial usage; technical issues or needed process changes will be discovered during the project. In addition, perceived business needs may change over the life of the project. It's important that the executive sponsors understand, however, that each major requirements change will cause some delay and wasted effort. Communicating this point clearly but pleasantly is one of the key challenges for the project leader, because the executives are as vulnerable to "happy ears" as anyone else.
Continue to the next section: Creating a Salesforce.com CRM business case
Download Chapter 1, Planning ahead
Read other excerpts and download more sample chapters from our CRM and call center bookshelf
SalesLogistix is a trademark of SalesLogistix, Inc. All rights reserved. This work contains other companies' trademarks; when the publisher was aware of a trademark claim, the designations have been printed with initial capital letters. Those trademarks are the property of their owners.
The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. The procedures and methods contained in this book are provided on a strictly "as-is" basis, and their use is entirely at the reader's own risk. The author and publisher will not be liable for any incidental, indirect, punitive, special, or consequential damages (such as data loss or system problems) in connection with or arising out of the use of the information, methods, or procedures described in this book. The author and publisher make no representations that the procedures or methods herein do not infringe on existing patents or proprietary rights of any third party, or that they will work in every system configuration. We hereby disclaim any obligation for indemnifying or otherwise compensating the reader.
This was first published in June 2009