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.
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.
posted by Richard Boardman at 6:48 pm
<< Home