Purchased an off the shelf product. Leader in it’s class. Then Project says , what is the point in UAT??
What do you say to that?
1 Like
This assumes that the product will stand up in your live environment and integrate seamlessly with the rest of your digital workflow, because of course that always happens without any problems.
If your workflow is directly business-facing, if it handles money in any form, or is in any other way business-critical, your response should be “What’s the bottom line impact if this doesn’t work 100% from Day One?”
And I’ve seen companies spend good money on off-the-shelf tools and never confirmed that what has been delivered actually works, instead of the contractor thinking “Oooh, lots of money for very little work - result!!” Then that same company, six months later, wondered why a £38 million turnover came out as a £1 million loss…
If any bought-in product, such as a van or a piece of IT hardware, didn’t work, any company would be engaging with the supplier to get it put right - why should off-the-shelf software products be any different?
3 Likes
In truly agile environment (if such thing existed 
) UAT phase would not really be needed, as it would be embeded in the whole SDLC.
I think the questions that need answering from the PM would be along the lines of:
- If it’s used by internal users, can they perform their day jobs without any impact to what they were doing? Or do they need to modify their processes?
- If it integrates into an existing eco-system, have all integrations been validated before plugging in?
- Have the benefits stated by using this new system been measured? If so, how is that being tracked?
As always, it may be context specific, but whether it’s part of an internal test process or a collaborative session with the tool vendor, your specific needs should be validated before signed off for use. Whether this is UAT, SIT or any other acronym based testing 
2 Likes