Salesforce.com Secrets of Success: Executive Summary

This chapter is from the book

Salesforce.com Secrets of Success: Best Practices for Growth and Profitability, 2nd Edition

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, 2nd Edition

Learn More Buy

Your Role Once the Project Is Under Way

As soon as the SFDC project starts, the team will come to you asking for your department’s time—including some of your own time. The sections that follow cover things to expect during the project (particularly during the first quarter or two).

Detailed Requirements

Throughout the project, the SFDC team needs access to knowledgeable individuals in your organization to drill into the detailed requirements and rules of the road for the system. Fortunately, the team won’t be asking for a bunch of time or effort—and every hour you invest will have very high leverage. You will get a better system sooner if you make this small investment to ensure the team is building the things your organization really needs.

The implementation team needs three kinds of input, usually from three different levels in your organization:

• Business process and policy knowledge: This information lies at the heart of how your company does business, and the SFDC team will sometimes need to know the why behind a procedure or a tradeoff. This level of information is usually best obtained from a fairly senior manager in your organization.
• Details about how things really work or how they need to change: These data consist of the standard operating procedures, the wrinkles, and the exception-handling procedures that make everything really work. This level of information usually comes from people who have been around a while but who work near the bottom of the organization.
• The meaning and behavior of data: This information consists of knowledge about data models, semantics, interactions, and integrations among systems. This level of information is best known by quasi-IT people (employees or consultants) in your organization, with titles such as business analyst, system administrator, data specialist, or application architect.

Business Process Changes

Don’t think of SFDC as being solely focused on automating sales or marketing. In fact, SFDC can be the basis for making business process improvements in nearly every customer-facing aspect of your business. An SFDC system doesn’t just speed things up; it helps you change the way you do business. Done right, SFDC can become the basis of competitive advantage and industry leadership.⁶

In thinking about business process changes, it’s important to push the implementation team to follow these best practices:

• Focus on things that matter to the customer: Emphasize issues that slow down the sales cycle or hinder customer interactions. Combine individual steps to make the process more sensible and systematic. The goal is to eliminate activities that are clumsy, out of order, patchwork solutions, or workarounds.
• Work on a few high-leverage processes that are naturally linked: Don’t try to “boil the ocean.” Fix things that are naturally related, not disparate elements from across the organization.
• Validate business rules: First, make sure the rules are still relevant and meaningful. The single most highly leveraged thing you can do in business process reengineering is eliminate obsolete or redundant rules, policies, or standards. If you must have a complex set of rules, make sure they provide something of beauty or value to the customer rather than just avoid a hypothetical negative.
• Remove paper from the process: As innocent as paper might appear, it is nearly always indicative of wasted time, increased error rates, and manual labor. Many organizations still use manual data entry—from data on paper—to link data across business processes. Replacing paper with on-screen steps and system integration will lower costs, save time, and increase professionalism. The on-screen updates will make the workflows much easier to monitor, measure, and improve over time.
• Increase information sharing: While being mindful of security and compliance issues, sharing information is the first step to effective collaboration. Better collaboration means faster identification of problems and unintended consequences, while creating more meaningful measurements at every level of the organization.
• Bake in measurements and thresholds: You can’t fix what you don’t measure. If there is a clear metric that is meaningful to the customer (e.g., “number of hours before we got back to the customer about a problem”), add thresholds, alerts, and automatic escalations to the new process so that management can see problem areas before they boil over.
• Minimize manual exceptions: Although human judgment is what sets great businesses apart, you want to minimize the judgment calls. And even exceptions need to be handled in a methodical way in your business processes. MBE forces you to systematize and streamline how you handle up to the 97th percentile⁷ of the business process. Not every step of the exception-handling procedure can be automated, but the entire exceptions process should still be systematized and measured so that the organization doesn’t spend too much time on the unusual cases.
• Optimize globally: Keep your eye out for suboptimization and siloed thinking. Discourage “over-the-transom” behaviors because they don’t help anybody and they usually hurt the customer. The point is to make the entire system (your company) work better, faster, and more pleasantly for the customer. That said, expect to find significant business process variations in your international operations, and know that the SFDC system will need to be modified to accommodate them.
• Keep it practical and immediate: Even though business process engineering has to consider big-picture effects, focus your energy on improvements that can be measured in the here and now. Don’t let tasks get ridiculously complicated or let perfectionism creep in.
• Ask for workflows; look for diagrams: The whole point of business process improvement is streamlining and workflows. By having a clear delineation of business processes, you establish metrics and thresholds for what’s normal and what’s a variance. In the SFDC system, business process workflows may be triggered by deadlines, customer actions, and thresholds. These workflows free up people from the mindless tedium of repetitive actions and allow them to start managing by exception. Workflows also make the important parts of your business more measurable.

The Touchy Side of Business Processes

Ideally, the SFDC team focuses on improving a small number of business processes rather than fostering a wholesale replacement. Refining or streamlining an existing business process involves a lot less stress and uncertainty than starting from scratch. Plus, if you are upgrading a business process that exists, it is easier to establish valid (and achievable) comparative metrics (e.g., 20% fewer errors or 10% decrease in labor costs).

There can be a lot of politics involved with a big business process change. In some cases, you’ll be changing the daily tasks of workers—or even changing their jobs entirely. The uncertainty inherent in this kind of change can lead to a lot of questions, endless meetings, and user resistance—even if the workers are given orders from on high. You may even want to include HR issues in your thinking if jobs are going to be redesigned in a big way.

Sponsorship and Escalation Path

Probably the critical success factor in any CRM project is strong executive sponsorship—from day one—that propels the implementation team and the end users into action.

When prioritizing and trading off requirements, the SFDC project leader needs a set of executive sponsors who can act as champions for the project when political and resource issues arise. For project success, the champions must include the VP of sales but will also usually include the VP of marketing, the VP of support/service, the CFO, and perhaps even the CEO. Championship is about making sure resource commitments and policy changes happen, so this responsibility can’t be delegated very far down the organizational hierarchy. Fortunately, filling the champion role probably requires only a couple of hours per month for the key VPs.

As the project champion, you’ll also need to break logjams on escalated issues. Because the SFDC implementation team works fast, it will make a big difference whether you resolve issues this week versus next. Team members won’t ask for your intervention often, but when an issue is escalated your way, you must respond quickly.

Management Council

Corporate VPs cannot afford the time to personally participate in the SFDC project, but the team needs access to some senior knowledge and judgment on a regular basis. You need to deputize a senior person on your staff to be a regular participant in the SFDC implementation team. The SFDC project leader will 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 SFDC product manager). A small management council would include representatives from sales and marketing plus the project leader. A larger council might add representatives from finance, customer care, international operations, professional services, channel operations, and business analytics. This council will need to hold brief meetings on a weekly basis.

The management council will probably handle most escalations. With luck, at least 80% of escalated issues can be decided there, but sometimes budgetary or policy variances require the intervention of the sponsoring VPs.

Team Members

Some of your staff members will need to devote significant time to the tasks mentioned in the section “Getting the Right Resources Committed” in Chapter 1. These team members will be charged with delivering documents and making binding decisions at a detail level, so you’ll want to assign individuals who know their stuff. Their effort on the team must be part of their “day jobs,” so you need to dedicate a portion of their schedule and allocate some of their personal goals (MBOs) to this endeavor.

Agile Project Reviews

As an executive, you’ve been trained to look for a budget that’s firm and a schedule that has a clear end date. Unfortunately, large systems projects don’t fit that model too often. High degrees of command and control just don’t work with software projects. Also, Agile project management—which focuses on quick cycle time and high-quality delivery of only the features that are really needed—can create a frustrating uncertainty about exactly what will be delivered when. You need to give the project leader some wiggle room so that he or she can deliver what matters, sooner.

CRM systems and processes must be highly adaptable to evolving business needs, so they are never implemented with a predetermined and fixed architecture the way a building would be constructed. Focus your attention on the cutover (go-live) date for the features your organization needs, and emphasize the absolute minimum acceptance criteria that must be met to achieve the go-live goal. Most significant SFDC implementations are replacements for previous systems, and it should be fairly straightforward to identify the criteria needed 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 the understanding that the system will continue to improve after the go-live date. In many areas, the company will need only 50% of the SFDC functionality on day one 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 make realistic decisions and tradeoffs. For example, it might be a great idea to manually approve orders for the first month of operation as a double-check of the system’s automatic order approval rules.

Agile Project Deliveries

Agile projects focus on frequent delivery of functionality so that something of value is made available to the business twice a quarter. That doesn’t mean that your organization will get wonderful new features all the time, but somebody in the corporation will get an important improvement on a regular basis.

When a new feature is being delivered to one of your groups, it’s important that employees participate in its final testing (to make sure they’re getting exactly what they need) and receive appropriate training. The training sessions will be short and nondisruptive, and they will save your employees a lot of time and misunderstanding. Make sure your organization knows that training is mandatory.

Of course, SFDC is still software, which suffers from the “iceberg phenomenon”: the toughest work in the project relates to infrastructure and data cleanup that has no visible feature, no immediate “win” for any department. Nevertheless, this infrastructure effort (particularly at the beginning of the SFDC project) lays the foundation for the features that will benefit the company as a whole. Solid, reliable data—which will give you visibility and automation you need—don’t come for free.