Search Content


Content Categories



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.



Related Custom Application Development Articles

Google Homepage - The Future Face of SaaS?


Software as a Service (SaaS) continues to gain momentum in the enterprise and is on its way to becoming a $20B market by 2011 (industry estimates from CSFB and Tripletree). Google, with its ďiGoogleĒ homepage, provides enterprises a single view...

Read more about Google Homepage - The Future Face of SaaS?...

What Blogging Means To Me (And You)


Note: This is part one of a three part series on my predictions for 2009 (see part two and part three). I will be covering predictions for blogging, HR and those made by others as the new year approaches....

Read more about What Blogging Means To Me (And You)...