Tips from the PM Trenches #2

Vendor User Acceptance Testing (UAT) Lengths

Dropping another tip while we put the finishing touches on our PMO Maturity Model usage series. Let's talk about vendor driven UAT planning.

As we enter the busiest time of year for kicking off new projects one of the things we see create issues with major vendor initiatives is vendor defined UAT periods.

It seem innocuous enough, as part of the contract for an implementation your vendor will have their default UAT period defined. They may present this as the norm across similar implementations. In our experience, over dozens of major projects, this is really a 'best case' scenario.

UAT extension is not a project killer, however it potentially can cause negative downstream effects to your planned release, marketing, and training as your UAT date continues to slide out into the future.

We have found two problems with accepting a vendor defined UAT period. The first issue is that it almost always takes longer than the vendor expects. Internal resource availability, test case creation and iteration, technology issues, they all add up to delays.

The second is a lack of functionality on Day 1 of UAT. We have seen multiple implementations where the full system function was not available on Day 1 of UAT but you are still expected to hold to the contractual timeframe. Not optimal, in some cases, not even possible.

We have two recommendations.

One - 1.5x or 2x the vendor recommendation for UAT. They will push back because additional resource time cuts into margins; push this as a non-negotiable.

Two - Add contract language that states UAT does not start until all (or X% if you are feeling daring) of system functionality is available. You want to be able to test the full system on Day 1. Don’t put yourself in a situation where you are testing partial functionality.

Your UAT success is one of the biggest drivers to overall project success, advocate to give yourself enough time to improve your chances of success.