Salesforce.com Secrets of Success: Planning Ahead

This chapter is from the book

Salesforce.com Secrets of Success: Best Practices for Growth and Profitability

Learn More Buy

This chapter is from the book

This chapter is from the book 

Salesforce.com Secrets of Success: Best Practices for Growth and Profitability

Learn More Buy

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.

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.

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 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 will look something like Table 1-3. Note that this schedule 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.

Table 1-3. Schedule for Small- to Medium-Sized Company SFDC Project Phases

• 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–5,000 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–5,000 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–5,000 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 person-weeks, 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.