Sales force automation
by John Goodpasture, Art Patterson, Ken Wyckoff
IMPLEMENTING AND DEPLOYING sales force automation (SFA) to a commissioned field sales force is a daunting task. With failure rates for sales force automation implementations estimated by various industry experts as 70–75 percent, this failure rate is far worse than that cited for projects overall and worse than the figures routinely touted for software development projects. Why the dismal track record? One reason is that sales people just don't like their processes automated. Automation requires rules. Sales people generally exhibit a great deal of creativity in order to overcome a prospect's objections, and they feel that systems with rules are too constraining.
Yet the project that we are about to describe successfully deployed a SFA deliverable to over 1,000 sales representatives, with technical and operational solutions provided, using project management methodology.
Charter and Scope of Project SFA. The project charter, developed from our strategic plan, was provided by the executive sponsor, a member of a top-level executive steering committee empowered to establish projects of strategic impact to the firm. This top-level authority; chaired by our chief operating officer, established the business case for SFA based on the market positioning of the sales force and operating benefits to the shareholders. The charter directed that an automation capability be deployed to our sales team which would not only provide sales support but also performance reporting of the sales process to sales managers.
Beginning with a valid scope was key to project success. With such a poor industry track record, we questioned what deliverables might be successful in the hands of the sales people and how to roll them out to a large sales team and gain acceptance quickly. We knew that rollout was going to be a major portion of the project WBS, and that those rollout activities and tasks would be critical to success. One identified risk was that there would be “late adopters” who, in spite of training and encouragement, would upset the business equation and delay benefits. Worse, if the late adopters became orphans to the SFA sales process, the project would fail on the quality goal of “satisfaction of needs.” Risk identification, vital in a project predisposed to failure, began early. Ensuring a complete WBS during scope definition became a critical step.
John C. Goodpasture is vice president of Process and Legal Services at Lanier Professional Services. At the time of this project, he was director of the project office for Lanier Worldwide Inc., responsible for project methodology and leading projects. He has 25 years of experience in project and program management.
Art Patterson is the program manager for Sales and Marketing at Lanier Worldwide Inc., including all sales force automation applications. He has more than 15 years of experience in the information technology area and 10 in providing applications to support the sales and marketing function.
Ken Wyckoff is vice president of Process 2000, a multiproject program with an ongoing objective of developing new processes, stimulating continuous improvement of existing processes, and sponsoring new projects of strategic importance to Lanier.
Sales Order Process Value Chain
Exhibit 1. Sales-to-cash has many value steps. The project began by identifying all the steps in order to optimize the use of SFA.
Prospect to Order Process
Exhibit 2. The SFA Project scope is “prospect to order.” This subset of the Sales Order Process Value Chain was identified as the best fit for an SFA project.
To identify all of the relevant product attributes, we reviewed the entire order process from the point from lead creation through product delivery to account service. (See Exhibit 1.) We identified several key areas but decided that from prospect-to-order was really where sales force automation fit best. (See Exhibit 2.)
Within the prospect-to-order process, we identified two primary operational activities: prospecting and sales. Within those activities, we identified the major tasks, including lead generation, planning, assessment, development, agreement, and order. These operating activities formed the basis of the requirements that Project SFA had to satisfy. Developing a WBS of deliverables became a task in allocating requirements to major components, and then decomposing those components to a sufficient level so that we were sure we had all that was necessary for meeting sales team needs. Most of the components were software applications. The project scope was to develop and deploy a first generation of applications that would support each of these prospect-to-order activities. Change control was implemented with a change control board that reported to the executive steering committee.
System Architecture for the Sales Force. Recruiting the right resources was key to establishing the proper architecture. Project SFA operated as a “tight matrix,” with the team co-located in a corporate project office established for high-impact projects. Among the members of the team in the project office were sales people recruited from the field for “duty” on the project. These subject matter experts (SMEs) provided valuable insight into what would make a difference in the field. Other SMEs were drawn from the sales force automation consulting community.
We began with process analysis. A key value-add from the sales representative's standpoint was that SFA would replace the sales price binders, reducing the amount of paper used. It replaced all of the product information and provided access to product analysis information, which the sales person uses to perform side-by-side comparisons between our products and our competitor's. All of this functionality was incorporated in a Marketing Encyclopedia (ME). Marketing Encyclopedia ensures that our sales teams are presenting the same consistent message to all customers. If our firm had a national account representative calling on a customer in New York, the presentation was the same as that shown to a customer in San Francisco.
Other components of the architecture are shown in Exhibit 3. The Opportunity Management System (OMS) is basically a database to manage information regarding sales opportunities and allow our sales management to help coach representatives through the opportunities.
Initially, OMS accepts qualified leads from our Sales Development Center (SDC), which develops prospects and provides a qualified opportunity to our sales force. OMS also provides the ability to store the information, retrieve it, and create a permanent database record, which helps maintain customer quality over a long period.
Zero Defect Order, our product and pricing configurator, takes the order through the configuration and pricing steps. This ensures that our sales representatives are putting together valid configurations to satisfy customer needs.
Managing Project SFA. Beyond the tight matrix, project office, and dedicated project manager assigned at the charter approval, all the knowledge areas of project management were employed in our project—a winner in the sales force automation industry. While scope management was of major importance, time, risk, and quality management also played a role in the success.
Time Management. One common question is, How long did it take to do this project? We started in February 1996 with a WBS for the four basic application modules. All four modules were fully implemented by April 1997. Since initial rollout, we have continued to upgrade functionality. We are in our second generation of each module except for the ME, which is updated bimonthly as an operational process of our firm.
The project schedule was developed from a network of activities taken from the WBS. Several techniques were employed to get a realistic schedule: After dependencies were developed, we evaluated the resource requirements. Resources came from our own employees, consultants, and from the module vendors. To take advantage of Monte Carlo simulation to reveal architectural weaknesses in the network, only finishstart dependencies were employed and we fixed no constraint dates. Fast-tracking joint application development and rapid application development ensured that we delivered this product right the first time. Rapid application development is a form of a crash technique, developed in the software industry, which employs prototyping and looping. It trades scope for schedule at variable cost. Remember that our charter's business case rested heavily on getting SFA into the hands of our sales force as quickly as possible. Naturally, these development techniques do not sort well with conventional PDM network scheduling because loops are not supported. Thus, we encapsulated the loops in conventional activity descriptions but used Monte Carlo simulations to estimate the effect of looping on the project timeline.
Sales Force Automation Deliverables
Exhibit 3. SFA architecture is multimodule and provides benefits to all stakeholders: sales people, management, and customers.
Risk Management. The risk management plan encompassed identification, quantification, and response development. Most identified risks were cultural, so our sales SMEs were invaluable, although we had to overcome the challenge of getting them to accept the systems and expend significant effort in making them feel they were part of the selection and development process.
Reader Service Number 054
Quality Management. Because of the concern about late adopters, quality management focused on satisfying user needs. Again, the SMEs from the sales team were invaluable. The quality plan's primary attributes were ease of use, the logic of the modules, module integration, the appearance of the SFA tool in front of the customer, and the training required to bring the sales force to a level of comfort and confidence. Our consulting team was instrumental in helping with change management, training, and rollout. We envisioned that our “fitness to need” quality goal, while achievable, would be more so if we had extensive field experience and user feedback between major releases. Our plan was to achieve a robust portfolio of capability in steps, or phases. In the software industry this is handled by planned releases. Whether you categorize this strategy as a risk management or quality management technique is less important than the result achieved. Reaching beyond “a bridge too far” is often the undoing of otherwise well positioned projects.
Reader Service Number 004
AS ONE OF THE FEW really successful projects in the industry, Project SFA provides some important key lessons learned:
Push hard for real change in business process and philosophy, employing a fully committed top-level executive sponsor. Push the organization to make changes faster than is comfortable. Recognize that overcoming organizational inertia is extremely difficult and that benefits from process change accrue more slowly than expected.
SFA is primarily a business change, not a technology issue. Sales management must be willing to change the way they do business.
SFA must have champions throughout the organization, and they can't be from information services. They also can't be someone from corporate telling the sales people, “You are going to use it!” It has to be someone who is going to be working with it on a day-to-day basis.
Cross-functional development, including co-located and full-time staff, is effective.
Standardization is critical. If you can't standardize it, you can't manage it.
Consultants and SMEs are very necessary, but challenge the recommendations from consultants to be sure of their applicability and practicality.
Train early and often.
Keep it simple. The sales representatives don't like to have a lot of information they have to fill in, and they don't like a lot of glitz.
Keep the SFA vendors committed to your success by working the relationships constantly.
Position the SFA environment to change quickly. You can't do it just one time or once a year and expect success. Put infrastructure in place that allows for quick change.
Selling is an art, not a science. Room for creativity must be provided within a controlled environment. There are certain things that you have to allow them to change, and there are certain things that you know you don't want them to change. Don't sweat the small stuff!
PM Network September 1999