CRM Selection: Getting Requirements to Reflect Reality

Perhaps the most important thing you can do before buying business software is to understand what you really want. Software is different from buying a car — a physical thing you can inspect and whose operation you understand. It’s different from buying a commodity, whose characteristics are already clear and there’s little variation from purchase to purchase.

Buying software is buying something abstract. Technically, you are paying for the ones and zeros that make it up — but that’s not what you’re really buying. You’re buying the idea of what those ones and zeros can do for your business. You’re paying for something that can automate a process, deal with data — and in some happy cases, permit you to do things you weren’t able to do before.

That’s what makes it somewhat challenging to buy: You need to flex your imagination to envision not just what a software package can do, but what you need it to do. That means thinking through your requirements.

Hard Thinking

Determining your requirements takes a lot more thought and effort, and it is more arduous than just looking at vendors’ solutions — which may indicate why it’s often done so poorly. Even when it’s done well, it can go awry. Once the requirements are defined and the software purchase is under way, requirements may change. That can spell disaster, since it means the software is already out of step with the needs of the company.

An exceptionally astute British CRM consultant, Richard Boardman, wrote about this in his blog several years ago. His pointers are pertinent to any software purchase, and he flags several areas where companies frequently fail to define requirements properly.

Among them is the tendency of companies to switch the focus to software features and away from actual requirements. Talking about features is easy: Just look at the sales collateral and compare the things vendors list. Whoever has listed the most things has the best CRM application, right?

Well, no — years of customers using this flawed method of comparison have taught marketing departments how to inflate their feature lists, often to prodigious sizes, but it hasn’t made their products any better.

A bullet-pointed list of desired features that makes no mention of the processes they are intended to support is worse than worthless, because it can drive decisions that work against the real objectives of the software deployment.

Instead, work the other direction, Boardman susggested. Start with the desired outcomes and then determine the processes needed to achieve them. Then, match the software features to the processes.

That sounds simple, right? Only it’s not. It challenges business leaders to use their imaginations to envision what their outcomes should be, and then to articulate the details of the processes needed to reach them. At the same time, it requires leaders to stick to a hierarchy of thinking: goals, then methods of achieving those goals, then the features that map to those methods.

Let’s Get Together

How do you do this? My suggestion is to make it a team effort.

Most CRM selections now are made by a committee of some type — generally, the VP of sales is involved, and the CIO or IT manager is on the team. Often it stops there, and the roles aren’t clearly defined. In some rare cases, actual CRM users are invited to be part of the selection process, and marketing may be asked in.

Marketing roles often are better defined, but they’re often limited to the user interface/user experience for the front-line users, and to marketing features for marketers.

Instead, the roles should be drawn more clearly. Since the task involves both over-the-horizon thinking and a need to stick to a hierarchy of thought, break those tasks up.

Let the VP of sales and the CMO get together to determine the business needs facing the company today, and have them put together a “dream sheet” of what they’d get from an ideal CRM application. Then, your CIO or IT manager can use that input — with input from sales and marketing — to match goals to processes and processes to features.

While it’s seldom done, it’s vital to bring in a representative group of CRM users as the list of possible solutions gets shorter. They can identify interface issues and process mismatches, either disqualifying vendors or identifying possible configuration changes for IT to tackle later.

By the time this process has run its course, you should have an understanding of your real needs today and your desires for the future, which then can be translated into requirements that align with your business’ reality.