Search Content


Content Categories



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.

Related Apex API Articles

Revenue Sharing on a Multi-Author Blog


You are the admin of a team blog that has multiple guest authors. The revenue sharing arrangement is such that all members get to keep a fixed percentage of the AdSense revenue that is generated from pages / articles that they have...

Read more about Revenue Sharing on a Multi-Author Blog...

Guest Post: Handling a Referral in a Job Search


With the economy headed south and tech feeling the pressure, many of you may soon be looking for a job. The best path is through a referral from a former colleague or friend. That's how I landed my current role at salesforce.com (which is hiring...

Read more about Guest Post: Handling a Referral in a Job Search...