On CRM and User Acceptance Testing...

Having sat through countless sales presentations over the years where vendors have rhapsodized about their carefully honed implementation methodology I can observe that the reality rarely measures up to promise of the pitch.

One manifestation is the quality of what gets delivered into the user acceptance testing (UAT) phase where the client assesses whether the development work undertaken by the vendor meets their requirements. It’s at this point that the vendor can, to use a sporting metaphor, throw their client a ‘hospital pass’.

In principle, and according to the fluently presented glossy implementation methodology, what the vendor should provide to the client is a rigorously tested system, which can practically be waved through UAT.

In practice however, the rigorous testing phase can quickly be dispensed with if the vendor finds them self under time or budget pressure, and the client effectively gets landed with the vendor’s testing responsibilities, or worse, gets to try and test something that’s effectively still in development – the equivalent of putting up the wallpaper while the plasterer is still at work. What might have been a relatively trivial piece of work is transformed into a death march as the bug count ratchets up and up.

Just to make this all slightly more pressurized, because UAT is pretty much the final step before live, most of the associated live activities are all now scheduled, and there’s relatively little scope to move dates out to reflect the unexpected influx of work, and so the test team ends up absorbing the workload the best way they can – generally dispensing with life’s luxuries such as sleep.

There are however a few things that can be done to help address this:

Have a detailed mutually agreed and understood design specification that gives you something to test against – this limits the scope for misunderstanding as to what should be delivered

Give yourself plenty of wiggle room in the project plan in order to absorb the unexpected developments that will inevitably occur.

Pay for implementation work on the basis of achieving defined milestones, and make sure one of those milestones is the delivery of a high quality system into UAT. I’m also wondering, though I’ve yet to try it, whether it’s worth offering vendors bonuses for hitting quality targets, just because of the potential downstream savings.

Make sure your vendor has scheduled for resources to be available to quickly fix the issues you identify, because if developers get allocated to other projects, you could be facing a long wait.

Assume the worst, because you’ll generally be proved right, and allow more time than you possibly think you’ll need.

In summary, while UAT is one of the final hurdles in the implementation process, it’s been responsible for more than its fair share of project delays, and has tempted many a project into the potentially fatal act of going live with a part-cooked system. As with many aspects of CRM implementation, it’s worth treating cautiously.