Developing a CRM implementation schedule

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:

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 underdelivering.

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:

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.

Outsourcing

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:

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 enddate. 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:

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

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.