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

The final major flaw with the functionality led approach to CRM requirements gathering is the Rumsfeldian notion of the unknown unknowns. Users, who invariably haven’t used CRM technology before, are expected to articulate a complete vision of what they want from a system, and invariably are only able to produce a handful of bullet points.

Even those who have been exposed to CRM technology before, generally because the system they used wasn’t well set up, and/or the deterioration of memory over time, and/or their exposure to a limited sub-set of functionality, tend to struggle to produce meaningful requirements.

On the other extreme, this approach does occasionally produce users who can create a very detailed but ultimately Frankenstein-esque vision of a system out of all context with what’s deliverable from conventional CRM technology.

The implications of the above are that:

The stated requirements are so limited that most packages in the market can meet them, and so the meaningful comparison is nigh on impossible.

Key functional requirements are missed which increases the risk of purchasing a CRM package that doesn’t meet the ‘real’ needs. For example I’ve seen a lot of organisations with very sensitive data security needs fail to document any data security related requirements.

Or in the ‘Frankenstein-esque’ situation the stated requirements are so ‘unusual’ that vendors are discouraged from bidding, and those that are received have huge price tags. I know of several expensive CRM tendering exercises that produced no responses at all, with all invited vendors deciding to ‘no bid’.

Anyway, that rounds out why the functionality led approach to requirements gathering doesn’t work, next time I’ll try and articulate a better way…

And now also Tweeting....

Had I been a venture capitalist a few years back, and, had I entertained a pitch from the folks looking to develop Twitter, then here’s what I would have said (choking back tears of laughter): ‘OK, so let me get this straight, you want to develop this site right, and it’s like a blog right, but your big thing, your really, really killer differentiator, is that your going to limit the blogger to – what was it again? Oh yeah 140 characters!?!?!......’

I didn’t get Twitter. Like I didn’t get why someone might not be satisfied with their standard mobile ringtone – still don’t for that matter. In the end, and solely because a friend twisted my arm with sufficient violence, I signed up for Twitter and started to ‘Tweet’.

A couple of months on I probably still don’t fully get it, but I’m finding it oddly addictive. I’m not sure from a marketing or promotional standpoint whether it can or can’t add value (and that’s not really why I do it anyway), but as a means of accessing a torrent of information from the people you choose to follow (mine include Lance Armstrong and Guy Kawasaki), it’s unrivalled.

My own Tweets are an eclectic mix – the last 48 hours or so have included Coventry City FC, the M25, Port of Spain, and a bit of CRM, and are probably best branded work in progress. Should you already be tweeting and want to follow, you can find me here.

Six tips to surviving CRM design hell...

Having spent the past six weeks in CRM design hell, I thought I’d share some tips on surviving the process while it was freshly seared on my memory. Trust me, CRM design work, rather like a prolonged course of dental treatment, isn’t the most fun way to spend your time. For those of you who haven’t been through CRM design before, it’s probably appropriate to first explain what it is: CRM design is where, having selected the CRM technology you wish to implement, you sit with your chosen vendor, and work out how your CRM requirements will be delivered in the new software.

On the surface this might not seem exactly onerous, but what you agree at this stage is what the vendor will go off and create, and if what they create doesn’t turn out to be quite what you wanted, then the vendor is likely to point out that, since you signed your name in blood that this was indeed what you wanted, they’ll now have to start all over again – and of course charge you for the privilege - so the project ends up taking a lot longer and costing a lot more than you intended.

In reality the design phase can be pretty straightforward, assuming the requirements are pretty close to the out of the box software. If however you require much in the way of customization or integration, the design phase will normally incorporate the dreaded design specification which you will be tasked with reviewing and swearing the requisite blood oath on the life your first born by way of confirmation of its accuracy.

Reviewing design documentation is to say the least challenging, so my six tips for surviving the experience:

Start with a good set of requirements – I won’t dwell on this as it’s a frequent theme in this blog, but suffice to say if you have a detailed well thought out set of CRM requirements - apart from saving you lots of money – it gives a ready means of checking off that everything you previously said you wanted is indeed what your vendor is planning to give you (vendors having tendency to slightly selective memories when it comes to things they feel might be awkward/expensive to develop).

Do not expect it to be in a language you understand – Design specifications are written for two audiences: you, as the client to sign off, and the vendor development team so they know what they’re meant to be developing, but actually mostly the vendor development team, who are generally extremely technical, which you may or may not be, and work with the selected software day in day out, which you probably don’t. So it’s a bit like being asked to sign a contract which is written in, say Greek, when English is your first language. So allow a lot of time (even a straightforward design document can take several days of work), and stock up on coffee and paracetamol.

Make sure you understand every word – Even innocuous phrases can have deep meaning, so these documents don’t suit a quick skim. The greatest mistakes I’ve made on projects have been where I’ve figured something’s been too arcane for me to take the time to fully understand, so my advice is no matter how dumb you feel the questions may be, keep asking them until you are 100% certain you understand what’s being said.

Expect trouble – You might be wholly convinced that your selected vendor are a pretty switched on bunch, and they might well be, but they will still make mistakes and omissions, and a lot of them, so don’t get lulled into thinking that you can trust them, and avoid the necessary investment in coffee and paracetamol. Even on a modest requirement I figure the vendor has done a pretty good job if I find less than a hundred issues on the first pass.

Finished reviewing? – the journey just begins – While you might feel a sense of a job well done having completed your review of the design, there’s normally plenty more to do. Curiously, many design specs have more mistakes in their second iteration than the first – a phenomenon for which I’m unable to offer any logical explanation. Half a dozen iterations isn’t that unusual for a moderate amount of customization, so budget for coffee and paracetamol accordingly.

Make sure the vendors have the resources available to action your input – You’d figure it wouldn’t surprise vendors that clients actually reviewed their specs, but it seems to. Once you’ve completed your review you would hope the vendor would be able to process your input in a timely manner, but if the relevent staff member has been allocated onto another project this isn’t going to happen, so it’s always wise to make sure that resource is available to quickly process the necessary changes, otherwise very lengthy project delays can ensue.

While this post is slightly tongue in cheek, the design phase might seem innocuous, but it really does catch a lot of organizations out. Very substantial overruns can easily result, so it’s really worth the considerable investment of time and energy required to get it right. There aren’t unfortunately any short-cuts, but coffee and paracetamol really do help.