Get tips for developing a CRM implementation schedule and setting executive expectations for your CRM or SFA project...
in this chapter excerpt. Also, learn some rules to follow if you're thinking about outsourcing some aspects of your CRM project implementation. Also, learn how to develop a straw-man schedule and how to avoid scope creep with your CRM implementation.
Salesforce.com Secrets of Success: Best Practices for Growth and Profitability
Chapter 1, Planning Ahead
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
Developing a CRM implementation schedule
Developing a Straw-Man Schedule
Part of making the business case for SFDC involves answering the question, "How soon can we get the benefits?" Once the project is approved, the schedule will be the single most visible aspect of managing the implementation. While SFDC and other SaaS systems can be turned on in a day or so (the SFDC sales reps will have made sure to tell you that), the standard system that is delivered will be of no practical use until it is configured (somehow the SFDC reps may not have emphasized this point). The time to configure the system may be short, but the time required to think through and test precisely how you need the system configured will be just as long as it would be with enterprise software. And the biggest cost and schedule elements—integration and data import—are just as large and uncertain as they would be with a conventional system. In large companies with a sophisticated IT department, allocate time in your schedule for initial review meetings: even though SFDC is a hosted system, security and compliance reviews will be required before you're allowed to "go live." Given that unexpected delays may be tagged as "project failures" by upper management, estimating the schedule and setting executive/sponsor expectations appropriately are key success factors for delivering the project.
Excerpted from "Salesforce.com Secrets of Success: Best Practices for Growth and Profitability" by David Taber. Published by Prentice Hall.
As with any complex project, the SFDC schedule estimate has to be based on a reasonable best-case scenario: you assume that you won't make wrong decisions, that the right resources will be available when needed, and that there won't be any unpleasant discoveries along the way. To counteract this structural optimism, buffer elements must be added to the schedule during the riskiest tasks (such as development of a new software element or integrating an external system). Buffer elements must also be added during weeks that are critically constrained for sales personnel and executive management (e.g., sales managers are unlikely to be responsive to an action item during weeks 12 and 13 of the quarter, and no executive can be expected to attend an SFDC management review during the week of quarterly results and the board meeting). One of the first things a project manager should do is collect the calendar of "blackout periods" for each key resource. Immediately after completing this task, the project manager should identify "forcing functions"— external events with firm deadlines—that will likely drive the deployment calendar. For example, an annual sales meeting will be an ideal time to roll out new functionality and do user training.
Gantt Charts, PERT Diagrams, and Other Management Delusions
While developing the schedule estimate, it really helps to use a Gantt charting tool such as Microsoft Project. This kind of software is fairly straightforward to learn, and during the planning phase its nice charts can help persuade busy managers about resource commitments.
By contrast, it is a very rare project that will actually use the Gantt charting tool during the life of the actual project, because maintaining the data and updating the schedule require a tremendous amount of effort. Unfortunately, few project participants will be willing to update their own information, so maintaining an accurate Gantt schedule will usually fall to the project manager. Most of the time, the day-to-day schedule will take the form of a spreadsheet. Set expectations with management accordingly.
That said, when a new project phase starts (or, less optimistically, when a major rework of the schedule is required), it is a good idea to redo the Gantt charts. Store backup copies of the original chart files for comparison purposes, but develop new ones that show the expected work breakdown structure at an overview level. You can have hours of fun comparing the original schedule with reality, and develop lessons learned for later phases of the project.
Ironically, one of the major areas of schedule uncertainty is in requirements setting and prioritization. A very common problem of large IT projects is to over-specify at two levels: at the high level, creating requirements that have questionable or unknown business value, and at the low level, specifying things in too much detail. At both levels, over-specification creates a lot of extra work and often engages employees in a level of perfectionism that has limited payoff.
The idea behind "value engineering" is making sure that a requirement is going to be worth satisfying before you spend the resources to do so. The best possible investment you can make as a business analyst or project manager is time spent vetting and validating requirements, because every hour you spend can save days of effort later. Allocate double the amount of time you think you'll need for interpreting and prioritizing requirements, as "smoking out" a marginal or bogus requirement can cut overall wasted effort in half.
Although the iterative process of an Agile project (described in Chapter 4) helps to contain the risk, any significant project will require a large number of meetings to discover what the requirements really are, how to prioritize and sequence them, and what they really mean for the system implementation.
The Art of the Quick Win
From the outset, it's important to develop a wide collection of user-visible features that can be liberally sprinkled through the schedule to maintain the perception that progress is being made and that the project is delivering business value on a frequent basis. This "quick win" list gives the project leader a tool to manage expectations and counteract a known negative (for example, "For the next two weeks, you can't do X, but we've given you this cool new feature Y to make your day go better"). Sometimes, a quick win is preventing a problem from ever occurring again. At other times, it's creating an alert to automatically flag unusual situations or adding a new "toy" that will keep users interested.
The quick win doesn't have to involve a lot of technology—the less, the better—and it should never involve a lot of work. It can be something as simple as a "mashup" with a traffic map so reps can figure out which route to drive to get to their appointments. Fortunately, SFDC's AppExchange has hundreds of free add-ons that provide features for users. Early in your project, do a survey of the AppExchange to see which freebies you can drop into the system during the implementation. Create a calendar of the "goody drops" and reschedule them as needed during the project.
The project leader needs to creatively identify other opportunities for quick wins. Sometimes, just putting data in one place can create several opportunities for wins. For example, if you put all your employees' contact information into SFDC, which kind of reports could be generated? How about a mailing list for HR, or a birthday list for the administrative employees? These featurettes may take 10 minutes to implement, but each one can give you a week's worth of breathing room.
The sequence of phases can be as important as the amount of effort applied to the project, because the sequence of features determines which system benefits are visible to the users and sponsors. Unfortunately, even with SFDC some amount of effort will be required for enablers— infrastructure, integration, data cleansing, analysis, and testing—that don't deliver any specific feature (even though no feature would be possible without those functions). The resource for this infrastructure work needs to be planned first, before the visible-feature work is planned.
However, always have something for the users. A project that devotes more than two thirds of the effort to things without visible results will have a tough time surviving in most organizations. The project phases should start with the core of SFDC, and then add system extensions, external data, and external system integrations on top of a stable base. This order is preferred for two reasons: technical simplicity and user training. Users rarely have patience for training sessions lasting even an hour, so the amount of change you present to them during each session must be fairly small. You want users to become proficient with the core of the system that's immediately relevant to their jobs before you focus them on the fancier parts. Chapter 5 provides much more detail on training.
The early schedule for a deployment is realistic only for a fairly small implementation of SFDC and a proficient implementation team. Here are some guidelines to use as a sanity check on your schedule. Note that these recommendations are minimums, so it's fine if your schedule assumes slower progress. Many of these tasks can be carried out in parallel, so they may overlap on the calendar.
- Initial SFDC bring-up, including basic configuration of users, roles, profiles, territory assignments, security, and basic user training: 2 person-weeks per 100 users or operating country.
- Integration with your company's Web site and Web advertising campaigns: 1 person-week for a simple static system, 3 person-weeks for a full content management system.
- Integration with external email blasting or marketing automation systems: 1 person-week per system, but bugs and testing may make this much longer.
- Preparation for data import/migration: 1 person-day on the learning curve for each data source.
- Lead information import, including data cleansing, deduping, reorganizing, and enrichment: 1,000–10,000 records per person-day, depending on what kind of shape your data is in.
- Account import, including account renaming and hierarchy creation, deduping, and enrichment: 500-5000 records per person day, depending on how many sources of "accounts" you have and the shape of the data.
- Contact information import, including data cleansing, deduping, reorganizing, and enrichment: 500–5,000 records per person-day, depending on what kind of shape your data is in.
- Lead/contact activity and campaign history, including data cleansing, deduping, reorganization, and enrichment: 500–5,000 records per person-day, depending on what kind of shape your data is in.
- Opportunity history import, including creation of historical accounts, contacts, notes, and attachments as necessary, data cleansing, deduping, reorganizing, and enrichment: 40–5000 records per person-day, depending on what kind of shape your data is in.
- Price list, product structures (SKUs), and quoting rules: 50–500 line items per person-day, depending on the complexity of your products, pricing models, business rules, and update history. Due to the nature of price lists, integrating the full price list may require several weeks of additional analysis and restructuring.
- Contract history import, including data cleansing, deduping, reorganizing, and enrichment: 50–500 records per person-day, depending on the shape your data is in. Many companies actually have to scan or key in data from paper contracts, which obviously means even lower productivity than indicated here.
- Customer asset inventory import (such as serial numbers, license keys, and other purchase history info): 500–5,000 records per person-day, depending on what kind of shape your data is in.
- Support "ticket," "case," or "customer incident" data import, including creation of historical accounts, contacts, notes, and attachments as necessary, data cleansing, deduping, reorganizing, and enrichment: 40–5000 records per person-day, depending on what kind of shape your data is in.
- Internal reports and dashboards: 1 person-week for the initial "toy" versions, although just the meetings to decide about the reports and modify them can take that long. Note that reports and dashboards will continue to evolve, so expect this effort to require several person-weeks of work over the first year of system use.
- External reports, data analysis, and business intelligence: several personweeks, although it may take much longer depending on the amount of data to be analyzed and the tools used.
- Workflows, alerts, and basic automation: 1 person-week for the initial set, although making decisions about policies and business rules can often take much longer. There is often a surprising lack of clarity about sales territories, compensation plans, business rules, and other automation essentials.
- Integration with external systems: no estimate is possible without a technical analysis of the two systems. Even though several SFDC partners provide "out of the box" connectors to scores of external software packages, in most cases significant extra work is required after the initial connector is installed. Often, the two systems cannot be perfectly synchronized, so extensive data manipulation may be required to reconcile the two systems' data sets.
- It is almost impossible to budget too much time for data cleansing and integration projects. Don't try to be cheap—it will only hurt the project in the long run.
Avoiding the Big Bang Project
Throughout the process of "selling" the Salesforce.com project, getting the budget, and allocating the staff, expectations are being set about all the problems that will be solved. During this process, expectations are being set about the schedule as well—and often a fixed date (usually the first day of a fiscal quarter) emerges as an important corporate milestone. Finally, management develops expectations about the nature of the deployment, usually focusing on a system cutover, where users switch from the old way of doing things to the new system. And almost always, all of these expectations will prove to be wrong.
This story is as old as the computer industry itself. You don't have to believe me: Fred Brooks' classic The Mythical Man Month described how the larger the systems project, the more likely it was to be late. Even better, the further a project was into its schedule, the more likely it was that increasing the staffing and investment would make it even later.
The classic complete-system launch, sometimes called a Big Bang project, just doesn't work for software. It can work when there is military-style command and control: the Manhattan project, Operation Desert Storm, and the Apollo program are shining examples. But in business systems, it's hard to find examples where a Big Bang was a big success. Businesses don't have tight military hierarchies, and IT has a culture of trying to accommodate new business requirements during the project. This accommodation and tendency toward scope creep— particularly in software—is a poisonous cocktail. The Standish Group, an IT consultancy, published a series of studies that extensively analyzed failed IT projects. The Chaos Reports concluded that overblown requirements and overzealous adherence to large, monolithic deliveries were key warning signs of failed projects.
We'll discuss this issue in detail in Chapter 4. For now, be aware that the most important thing the project team can do before any project work begins is to avoid three things:
- Fake, vague, or overstated requirements
- Infrequent project milestones
- Large, complex, monolithic project deliverables
Avoiding Scope Creep
Scope creep is one of the most dangerous things that can happen to a project, and the danger grows in tandem with the size and length of the effort. This problem occurs whenever a requirement is stretched, an assumption made that "we can fit that in," or an even better idea is proposed by executives.
The chief symptom of scope creep: the requirements list grows while the project is under way. Because items aren't removed from the priority list, the number of deliverables grows even though the budget and schedule are unchanged (or worse, are being overspent by the project).
There's a particular temptation to load up the requirements even further whenever a project needs to get a schedule or budget extension, even though it should be obvious the project is already at risk of under-delivering.
The only solution for scope creep is vigilance among everyone on the project team, regular management reviews to root out new creepy requirements, a very persuasive project leader, and consistency on the part of executives. The project leader will need to develop political skills to escalate scope-creep issues without angering the people who are proposing the additional Great Things for the project.
Even if the project has been "sold" with a lofty set of goals and tight Big Bang deadlines, it is important to quickly move to a phased approach. This isn't just because of the IT "laws of physics"; it's also human nature. Put simply, change management and confidence building take time. For even small companies, reset executive expectations by making the following arguments:
- We all know what the desired end-state is going to be, and those goals have been agreed to. But until the project is fairly far along, we can't know which problems we'll find in our data, precisely how business processes need to change, or exactly what every user will need.
- Given this inevitable uncertainty, the best way to achieve our goals is to rapidly deliver a part of the project big enough to provide value to the business. This first delivery will give users a chance to learn the system and provide real-world feedback that will improve later system deliveries.
- Delivery after the first phase should be incremental, with each cycle providing a new element of value to the business. Having small, frequent deliveries makes it more likely we'll have happy users and low risk while meeting budgetary and schedule goals.
In making these arguments, the trick is to find the right "cornerstone functionality" to deploy for each phase, paired with the internal constituency you want to leverage. This decision making will be profiled in detail for each phase as described in Chapter 4, but as part of selling the project you'll need to establish the constituency for the first phase's subsystem right now.
The best way to select the subsystem is to answer this question: Which system element could be deployed the soonest and deliver real value to a meaningful constituency? By producing a quick win, you earn credibility for the project as well as users for the system.
Almost inevitably, you will need to use some outsource resources to assist in the project implementation, and you'll want at least budgetary placeholders for them. There are many tasks that your internal team shouldn't want to get good at. Even so, you cannot outsource everything—your team must be involved to define business rules, perform data extraction, review prototypes, validate data conversion, do acceptance testing, and, of course, manage the project. One thing to insist upon is a full "technology transfer" from any consultant you use, so that your team becomes self-sufficient in any area of ongoing development or maintenance.
In evaluating and choosing vendors, follow these rules of thumb:
- The product vendor's consultants will know more about the internal workings of their product than any partner consultant can. They will also have direct access to product engineering, and will have several "back door" tricks that can save time and make their prices a bargain. For internal extensions, customizations, scripting, rule setting, query design, and other "deep dive" projects directly related to their own products, the vendors' consultants are likely to be the best choice. However, they are less likely to be the right people for external integrations or business process design.
- A specialist system integrator with a practice dedicated to SFDC or other SaaS product is likely to know best how to do "external work" that integrates across applications. However, these individuals' level of knowledge and skill regarding business processes vary dramatically. In fact, many firms that are fully qualified at the technical level have zero capability when it comes to understanding and optimizing business processes. Check references before you make specific task allocations!
- A technical "coding shop" typically will be very good in its particular domain (for example, enhancing a CMS-driven Web site or an external order management system), but those employees may not have experience with Web services and high-speed integration using SOAP.20 Even though most SaaS applications use Web services for integration, every vendor uses the core technology a different way. For this reason, it's important to check the vendor's experience with SFDC's APIs and any AppExchange products you're planning to use. As always, references are more meaningful than vendor claims.
- A consultant who already works with your company has a natural advantage over outsiders. In addition to already being "connected" in your organization, the incumbent consultant is much more likely to know a lot about your technical environment and at least something about your business processes. Check with your IT organization to find out who is already under contract. If you've got only a few person-months of work to do, the incumbent's advantage may be a decisive one.
- Data cleansing and enrichment houses can be very economical (using tools and offshore resources unavailable to you), but this part of the project must be done right and completely to be at all meaningful. Check whether the vendor has done work on your size database in an SFDC project: most have not, and they'll experience a serious learning curve. Check references to confirm the details, because offshore data cleansing/enrichment operations tend to overstate their capabilities and are very inefficient at learning to do new things.
- Management consultants, sales process consultants, and organizational design specialists understand the human side of your business processes better than any other vendor type. Large organizations will typically need to use these consultants to optimize business processes, redesign sales procedures, and set policies. However, these consultants are rarely in a position to do implementation work, because they don't understand the inner workings of SFDC and other systems well enough. The also have a tendency to make recommendations that are technically very difficult or even unfeasible to implement. So absolutely include them on your team to design best practices and increase the speed of user adoption—but do not expect them to implement much in SFDC.
No matter which kinds of vendors you use, it is essential that you have a positive, cooperative relationship with them. Adversarial relationships just don't work—in terms of price, quality, or schedule. That said, it's essential that you manage each vendor relationship tightly. Although you don't manage a vendor in the same way you would an employee, vendors are every bit as important to project success and budget as any other team members. Weekly checkpoints and monthly scorecards are essential for all vendors.
Generally speaking, there are several areas that you don't want to outsource. It typically doesn't pay to have an outside team learn the peculiarities of your old home-grown systems. An outsourcer should not be making policy and process decisions for your company (they can make recommendations, but you have to own the decision).
Even if a major technology is implemented by outsiders, your internal team needs to have ongoing capability and knowledge. For example, you'll want to be able to make simple system modifications without calling in a vendor, and it's a good idea to be able to make minor changes to cope with the inevitable upgrades of external systems or minor updates to business rules. In your resource allocation, think through which of the tasks must be done internally, which should be done through a vendor, and which should be done jointly.
Setting Executive Expectations
Executives have been trained to see a business case that's firm and a schedule with a clear end-date. Unfortunately, large systems projects don't fit that model too often. And Agile project management, which is designed to make quality deliveries of what's really needed in the shortest amount of time, creates a frustrating uncertainty about exactly what will be delivered when. The project leader must bridge that gap.
The first step is to convince the executives that SFA/CRM systems and processes must be adaptable to evolving business needs, so they are never completed the way a building would be. The next step is to focus attention on the cutover (or "go live") date, including the absolute minimum criteria that must be met to achieve this goal. Most significant SFDC implementations are replacements for previous systems, so it should be fairly straightforward to identify the criteria for the new system to be "good enough" to support the switchover. It is important to use terms like "good enough" or "acceptance criteria" to communicate that the system will continue to evolve after the go-live date. Some functional areas need to be only at the 80% level at cutover time to support the business.
As always, perfectionism does not pay. By focusing the discussion on what is really needed to support a given business process on a day-to-day basis, you can get realistic objectives and feedback on which tradeoffs could be acceptable at the go-live date. For example, it may be okay to manually approve orders for the first month of operation, so as to make sure that the automatic order approval rules accurately reflect your business policies.
The executives need to know that functionality will be delivered incrementally, and that their staff will need to play active roles in assuring quality over several phases. Executives also need to know when the key business processes affecting their specific departments will be done. Consequently, we recommend organizing the presentation of the schedule in two ways: chronologically, for the overview perspective, and organizationally, for each executive. Keeping the schedule in a spreadsheet (which can be generated from your Gantt charting tool) allows rapid creation of these executives' views, as shown in Figure 1-4. In this view, many tasks are repeated so that each executive can see the impact on his or her specific organization without having to refer elsewhere.
FIGURE 1-4 Executive's Overview of Deployment Phases
One of the biggest challenges of setting executive expectations is the iceberg phenomenon: the toughest work in the project is in infrastructure and data cleanup that has no visible feature, no immediate "win" for any department. Most executives don't have patience for these intricacies of the project, and the best way to talk about them is in terms of "laying the foundation" for the features they want to see. Foundational work typically continues throughout the project, and it's often best to depict it during all phases. Even so, every single phase needs to deliver some interesting feature to at least one department, so the executives don't become frustrated with the amount of effort expended on "invisible stuff."
Getting the Right Resources Committed
At some point, there will be a meeting to make the decision to move forward. Usually, these meetings focus on the immediate expenditures. In contrast, commitments for ongoing expenses and effort are assumed away or quickly forgotten—and that's dangerous.
For a truly successful large-system implementation, the following funds must be assigned to the project at the initial go/no-go meeting:
- Initial procurement funding for the system, add-on products, and any hardware or IT resources required.
- Ongoing funding for the recurring fees, added to the budget for at least two years.
- Fees for consultants and service providers needed to configure, extend, integrate, and deploy the system.
- Fees for training courses and user-group sessions offered by the vendors.
- Dedicated personnel, typically in the form of a time allocation with specific measured goals or MBOs:
- To make ongoing priority calls about requirements and schedules.
- To decide policy issues and business rules.
- To design approval cycles, exception handling, and workflows.
- To do actual work on the SFDC system, including data cleansing, record imports, and other housekeeping tasks.
- To do work on external systems such as: data modeling, data dumps, enabling external interfaces, doing testing, and other tasks.
- To assist with IT infrastructure tasks (security audits, installing wiki software, server deployments, and so forth)
- To do technical tests of the SFDC system and validation of its external integrations.
- To do user testing of the system.
- To run final acceptance tests.
- Regular (brief) intervals of executive time, to escalate issues, break logjams, reallocate resources, and do final approvals
Surprisingly, most executives tend to focus on the top of this list. In reality, the items near the bottom tend to cause the biggest issues with projects over time.
At the meeting, you'll also need to set general expectations—preferably quantitative metrics of success and criteria for a successful deployment—for the first phase. Without these objective measurements, executives tend to remember only the date for the first phase deployment, which tends to put people in happy-ears mode. Make sure to start the project off on the right foot, with documented budgets, schedules, and success criteria.
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.