Why Bob got fired and why the conventional wisdom on CRM requirements specification doesn't work...part two

Once upon a time in my career any sentence containing the word ‘business process’ would reduce me to a near catatonic state. I assume many others feel the same way, because the concept of business processes virtually never features in the many CRM business requirements documents I get to read. This is odd for a number of reasons:

Assuming our objective for the system is to be more than a play thing for the sales team to dip in and out of as they feel inclined, the only way for a CRM system to deliver the objectives we talked about in episode two of this series, is to use it in a consistent repeatable way in order to achieve our desired outcomes i.e. it needs to incorporate a set of business processes. So unless you get the processes right you don’t get the benefits.

Because the way you run your business is pretty much unique in at least some respects, CRM technology isn’t going to work for you straight out of the box. Therefore even if the technology you select has a standard way of doing things (i.e. its own business processes) these will not map precisely to how you do business. They may require a little change or they may require a lot, but somewhere along the line you’ll need to figure out how you want the system to support the way you do business and adapt it.

Let’s say you wanted to cook lasagna. You’ve never cooked lasagna before so your first step is to go to the supermarket to buy some ingredients. It would be pretty difficult to do this without reading the recipe first. You’re wandering around thinking ‘mmm, now when I had it before there was definitely some mince, and oh yes, cheese, not sure which type though, and herbs, yeah, there were definitely some of those….’. Chances are that while you’re going to get some ingredients right, you’re getting to get some wrong, and plain miss others.

CRM requirements gathering isn’t much different; until you fully understand the processes (recipe) it’s very difficult to work out the supporting functional requirements (ingredients). And, to torture the analogy some more, without the recipe it’s difficult to guess the time involved to prepare and cook your lasagna, and so with CRM, without understanding the detail of the processes, it’s very difficult to estimate how much work (and hence cost) will be involved in adapting the system to meet your needs. In other words it’s only with a detailed understanding of the desired business processes that you can flush out the functionality you need and the cost of customization.

Finally, business process definition can be surprisingly time-consuming. You may have robust existing processes which can be quickly mapped into a CRM system. You may not. I’ve seen managers reduced to near gibbering wrecks when I’ve walked them through how their existing processes actually work on the front-line. The implementation of CRM technology is often the trigger for existing processes to be re-evaluated and engineered, and entirely new processes introduced. While process development isn’t necessarily immensely time consuming, it generally is.

The functionality led approach to CRM requirements gathering pays little attention to the above considerations and therefore creates a number of the problems the likes of which led to Bob being fired:

The functionality led approach fosters a belief that all we need do is purchase the right CRM software throw it on a server and we’re ready to go, which is the equivalent of spreading the lasagna ingredients on the table and saying we’ve got a lovely home-cooked meal. Technology is a tool. It won’t produce results on its own. It requires business processes or it doesn’t generate results.

The full functional needs fail to get flushed out and so the risk increases of getting landed with an inappropriate technology.

Without a full understand of how much the out of the box system will need to be customized to support the yet to be specified business processes, vendor pricing proposals can only be estimates. This has several implications:

1. We can’t easily compare pricing estimates because one vendor may estimate cautiously another may game the system by putting in a low ball estimate, therefore we can’t compare apples with apples.

2. It’s virtually impossible to negotiate on a substantial part of the system purchase costs because they aren’t known at the time of purchase.

3. We won’t know the full extent of the requirements and costs until after we’re committed to a vendor. The fox now has the run of the hen house, and we can expect to pay on average around 50% more for the implementation.

Finally, because process development can be time-consuming, when this isn’t undertaken until after the vendor has been selected, there can be a big gap between initial outlay on software and services. This isn’t great from a cash flow perspective, but also fosters situations in which managers can make rash decisions to speed up a necessarily lengthy process, such as cutting back on user acceptance testing.

Next time around on why the functionality led approach to requirements gathering is fundamentally flawed, I’ll cover the problem of the unknown, unknowns.