CRM on the Cheap: 5 Strategies That Really Work

Your company has acknowledged that the business needs a new CRM system. But the CFO is nervous about the costs, and starts to suggest strategies that could lower costs-or doom your project to fail . Now's the time to keep your eye on the business goals as you make choices. For instance, how important are your company's procurement issues versus project management? What are the policies and business process improvements that will fundamentally change the economics of your CRM system?

In part one of this article, we described cost-containment strategies that typically backfire. Now we get to the tactics and strategies that really work. Although the advice focuses on Salesforce.com, nearly all of it applies to any modern SaaS CRM or SFA system.

Strategy #1: Ruthlessly Prioritize Given the political reality of most companies, prioritization may seem to be impossible. But even if nobody is willing to prioritize at the beginning of the CRM project, reality will have its way: by the end of the project, you will have only completed the most important stuff. So why not develop a plan that's in line with where reality will take you anyway? Here, the cost analysis tools of the CFO can be your friend.

Be sure to look at all the elements of cost, including: direct labor, indirect labor, procurement, implementation, "sunk costs," overhead, and even team morale. All the major requirements need to be evaluated on comparable terms, so putting all the requirements on a single spreadsheet is a first step. There are a bunch of free spreadsheets covering this at www.SFDC-secrets.com (when you're prompted for a password before downloading, use "CIO.")

Next, what about the business value of a requirement? Getting a bunch of executives to agree-and prioritize-on this can be an amusing exercise. Fortunately, there are a number of voting and consensus building tools available (get them for free at the website). None of the methods is perfect, but one of them will work to build a consensus among your team.

One final tool is "constraint-based" prioritization. For requirements of a comparable "size" or "business value," the ones that impose the fewest constraints on your organization should be done first (because they're the easiest to execute). Items requiring a specific resource that's currently unavailable will get bumped down the list (and outward in time). Sometimes, just the constraints can do a marvelous job of shortening the priority conversation.

Strategy #2: Question Requirements Requirements are easy to specify, but some of the most overblown descriptions are for things that aren't that important. In "The Chaos Reports," the Standish Group showed that mis-stated requirements are the most common cause of large IT project failure. The acid test is to ask the question: will this feature actually change a decision or result? If there aren't concrete examples, the requirement should be examined and restated in a way that it would change a business outcome.

One of my favorite CRM examples is dashboards about weekly lead production. This sounds reasonable, but lead flow is like Web site traffic: it's a better indicator of visibility, awareness, and vague interest than of a solid revenue pipeline. Visibility numbers (such as "impressions" or "press mentions") are very easy to game, so the numbers won't mean anything. You're much wiser to focus on direct indicators of business health, particularly when compared over time.