A friend and former colleague of mine mentioned this as one of her biggest frustrations that she has experienced in the Project Manager and Business Analyst roles she’s played so I thought it would probably resonate with many of the readers here as well.
Testing as a Priority
A client testing their product well before signing off on production…seems like it should be a top priority, doesn’t it? I once worked for a company in the gaming industry whose client was the largest player in that field. Every rollout of their poorly constructed software required heavy involvement on the client side for testing prior to implementation. It was so bad, that the client organization had to budget $1 million (I’m not kidding!) to thoroughly test the vendor’s software prior to rollout. Embarrassing indeed, but critical – the client valued the testing phase and knew the importance of preparation and thorough testing.
The UAT Process – Customer Responsibilities
I’ve discussed User Acceptance Testing (UAT) earlier as part of Project Phase 5 – Testing. I mentioned that it is critical that the customer come up with their own test scripts and testing scenarios in order to rigorously test the system prior to deployment. You would think they would want to!! After all, aren’t they paying good money for a well-developed, well-tested, and hopefully smooth-running system? And one of the key ingredients of a trouble-free deployment in the IT world is a rigorously tested system.
Yet, we all still see customers who come to the UAT table with poorly written or non-existent test scripts (no matter how long you’ve given them). Even though it’s a serious conflict of interest to have the delivery team create the test scripts for UAT, that’s what ends up happening in these cases. Because a good PM with a solid schedule knows well in advance when the customer is not going to be prepared for UAT. To that end, the delivery team does their best to mitigate this newly integrated risk by coming up – as arbitrarily as possible – with their own set of test scripts and scenarios for the customer’s testing team.
Hopefully, the customer has at least put the effort into assembling the subject matter experts (SMEs) for the UAT activity and worked hard to ensure that these individuals are available and free from other work interferences during this very critical task that has now been heightened in importance because of the lack of customer preparation.
Of course, if they haven’t, they have no one to blame but themselves. Unfortunately, even when the customer drops the ball on UAT prep, they will still point the finger at the delivery organization and delivery team – and directly at the PM – if UAT goes poorly and if the implementation has any major bumps.
Conclusion
As the PM, what do we do to safeguard the UAT process? Unfortunately, if the customer really doesn’t know how to prepare or perform UAT, there isn’t much we can do. At that point, we have to focus on damage control and that involves:
- Staying on top of the schedule so we can see the UAT issues coming up well in advance
- Assigning test script creation activities to the delivery team – primarily the Business Analyst
- Going onsite with the delivery team to hold the customer’s hand through the UAT process
- Obtaining official signoff – in blood! – of a successful UAT and guard that signoff with your life!
- Document the customer UAT issues (lack of test script creation and participation) very well in the issues list and review it during weekly calls – ensure that it is very visible and identified as a major risk
With solid involvement from the delivery team, a successful UAT can still happen. It’s just very unfortunate when the customer doesn’t put proper value on this critical process that occurs late in the project. It should be more important in their eyes and worth the effort.