In CRM Software, Cost Control Is Impulse Control

Behavioral economics has proven that we're all pretty bad at making rational decisions. So what are you supposed to do about it? Make the people who want shiny new software pay for it themselves.

The most expensive software requirements aren't the ones that cost a lot to implement. They're not even the ones with the biggest over-runs. No, the most expensive requirements are the ones that should never have been started, the ones with marginal or even fictional business value--and in CRM, like no other class of enterprise software, the parade of bogus requirements seems never-ending.

The root cause of excessive CRM customization requirements is typically one of the following:

  • CRM has been oversold by the vendor with dazzling demos and dodgy statements that let your team mislead itself into over-optimism.
  • Your internal champion has overreached in order to overcome internal opposition and get the project approved.
  • Users have worked with a "similar" CRM at other companies that over-customized their systems.
  • The executives just assume that "any CRM does this."
  • Users have overly optimistic assumptions about ease of use.

By now, everybody knows I'm an agile zealot, if not a waterfall bigot. The magic of agile comes from incrementalism: Building only what's inescapably required now and adding features over time so that the system can evolve with changing business requirements and political necessity. This lets IT escape the tyranny of "slash cut" programs and the inevitable issues of large, monolithic projects.

[ Commentary: Why the Last Mile of CRM Implementation Is the Hardest ]

[ More: Why CRM Implementation Needs Training Wheels, Not Racing Gear ]

Agile remains vulnerable to bogus requirements and sloppy thinking, though. Let's face it: Using squeaky wheels to prioritize can only take you so far. The shrillest voices are seldom the most rational.

Remember, Money Makes the World Go 'Round

Your friends in finance stand as the first powerful line of defense. There's nothing like a budgetary requirement to calm things down. The trick is making the requesting department pay for the improvements out of its own bucket. If there's one part of economics that always works, it's the pricing mechanism. Make sure nobody gets a free ride on somebody else's budget line.

[ Commentary: How Much Should You Spend on CRM Software? ]

[ Related: Why Your CRM Integration Consultant Doesn't Know Anything ]

Incremental project dollars are only part of the story; there are other "invisible impacts" of all new functionality. Organizations can't just assume these other ramifications away:

  • Most new features involve some new data. Who's really going to do all that data entry? If the data comes from another system, who's going to validate the data that comes over? Whose job will that be, and how much of his/her day will be consumed by this new task?
  • Most new features mean some new user interaction and automation. Who's going to validate that the new feature automates the right thing the right way? Who's going to handle the inevitable debate about the way the business process should work and guide the testing of that automation when questions arise?
  • Automation requires some training and hand-holding, particularly during the break-in period where users will point to things they don't like and call them bugs, even when they're required features and controls. Who's going to do that training and user support?
  • Almost always, reports and data extracts will be required. Who's going to specify what those reports do and validate the semantics of the underlying data and the information products? As I mentioned recently, unchecked CRM reporting is often its own Tower of Babel.

[ More: With CRM Data, More Isn't Always Merrier ]

[ Also: How to Solve CRM Data Deduplication Dilemmas ]

All those items are along the lines of "extra work, extra pain." It's important that these not be sloughed off as some poor schlub's uncompensated duty. Wishing costs away or hiding them yields bad decisions and burned-out workers.

CRM Software's Ends Must Justify the Means

There's another dimension to requirements: Their value to the business. Ease of use is important to user satisfaction, but it's hard to convince Wall Street that making it easier for your employees will be worth a penny of earnings. Guide the conversation toward the consequences of the new features. These include the following:

  • Will there be a measurable increase in revenues?
  • Will there be a measurable decrease in costs?
  • Will there be a measurable improvement in customer loyalty — something beyond just "better customer experience?" Will customers have an propensity to renew or repurchase?
  • What internal decisions will be made better or faster as a consequence of these new features? What decision or process will actually have a different, and more profitable, result?
[ How-to: 13 Tips to Get Business Teams to Use Your CRM System ]

[ More: Avoid These 10 Common CRM Mistakes ]

The business benefit will justify the expenditure, and measurability is the acid test for bogus requirements. If you work with sales, you can even use the ultimate Poison Dart: Have the department estimate how much improvement its requested new features will enable, then have the CFO ask to raise the quota by that amount. You won't make many friends, but the bogosity will instantly recede into the shadows.

Let the person who claims to need the new feature be the one who bears the initial cost of creating and testing the feature; the ongoing effort of inputting, validating and maintaining the data, and the time involved to get everyone trained and happy with the changes.

David Taber is the author of the Prentice Hall book, Salesforce.com Secrets of Success, now in its second edition, and is the CEO of SalesLogistix, a certified Salesforce.com consultancy focused on business process improvement through use of CRM systems. SalesLogistix clients are in North America, Europe, Israel and India. Taber has more than 25 years of experience in high tech, including 10 years at the VP level or above.

Follow everything from CIO.com on Twitter @CIOonline, Facebook, Google + and LinkedIn.

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies