Be afraid, be very afraid…

‘It’s not in the standard product…..but it would only take a couple of days of customisation to add it’.

Sit in on enough vendor presentations and it’s a phrase that you are likely to hear often repeated.

My tip – if you hear these words, be afraid, be very afraid.

The reality is that most of the CRM packages are very flexible, and ‘it would only take a couple of days of customisation’ is not wholly untrue.

What this sound-bite fails to convey though, is that customisation is only one link in a much longer (and more expensive) chain of billable events that might more accurately be characterised along these lines:

1.The implementer meets with the client to gain a detailed understanding of the required additional functionality.
2.The implementer documents the requirements and submits them to the client for approval.
3.Based on the approved requirements, the implementer creates a design for how the new functionality will be incorporated into the system.
4.The implementer submits the design documentation to the client for approval.
5.The implementer revises the designs based on client input and re-submits for approval.
6.The implementer performs the customisation work.
7.The customisations are tested internally and any bugs identified.
8.The implementation team de-bug the customisations following review by internal testing.
9.The implementers help the client set up a user acceptance testing infrastructure.
10.The implementer passes the customisations to the client for acceptance testing.
11.The client submits any identified bugs or functional shortcomings to the implementer for resolution.
12.The implementer and the client debate what constitutes a bug, and what constitutes a change request.
13.The implementer fixes the identified bugs, performs the agreed change requests, and re-submits them to the client for user acceptance testing sign off.
14.The client signs off on the user acceptance testing.
15.The implementer/client updates related documentation such as training and usage manuals.

And of course the process is only as short as this if everything goes reasonably smoothly. Add to the above, the additional associated project management overhead, and consider that client side activities such as requirements definition and user acceptance testing can involve several staff simultaneously, and that the considerable amount of elapsed time will delay the return on investment, then it’s wise to consider departures from standard functionality with some caution.

ShareThis