Why UAT Deserves Your Attention (and Your Calendar)
The single biggest leading indicator of a successful go-live.
A few articles back, I said that User Acceptance Testing deserves its own article. Actually, it deserves two. This is the first.
This article exists because it needs to. Over the years, I have seen good UAT, poor UAT, and everything in between. The pattern is consistent: the smoothest go-lives, and the smoothest post-go-live adoption, are almost always reflective of good UAT. That is not a coincidence. It is the single biggest leading indicator I have for how an implementation is going to land.
If you are leading a PSA implementation, participating on the implementation team, or have any stake in a successful go-live and in owning your system afterward, this is for you.
What UAT Actually Is (and What It Isn’t)
Let me say something I say to every client: UAT is not “we clicked around for an hour and it seemed fine.”
UAT is not smoke testing. It is not the consultant’s job. It is not a formality to check a box before go-live. And it is not a demo where someone walks you through the system and asks if it looks okay.
UAT is the phase where your team validates that the configured system actually does what your business needs it to do, using your actual work. Key words being your. Your system. Your process. Your work.
Well, technically your organization’s system. But if you are reading this, you probably have a stake in your team’s success, so for our purposes, it is yours.
It is also a team effort. Services, Finance, and IT all have to bring their piece of the process to the table and put it through real testing. Not silos. Not one department signing off for everyone. Every team that touches the system needs to have tested the part of the process they own.
Here is what that means in practice. If Finance is not testing billing and revenue recognition against your actual month-end process, you do not have UAT coverage on Finance. If the Services team is not testing time entry, project setup, and resource bookings against how they actually work, you do not have coverage on Services. If IT has not validated integrations with your source systems, you do not have coverage on integrations.
You need all of it. And that takes real coordination.
Why So Many Teams Get This Wrong
The most common UAT mistake I see is not technical. It is a mindset mistake: teams treat UAT as the last step before go-live, when it is actually the step that determines whether go-live works.
When UAT is treated as a formality, a few things happen. People show up unprepared. They click through a few screens, do not find anything obviously broken, and sign off. The system goes live. And then two weeks later, the complaints start rolling in: “The billing is not calculating the way we expected.” “The report is missing data.” “This field does not do what we thought it would.” “Why is this workflow routing to the wrong person?”
None of those are software problems. They are UAT problems. They are the result of a system that was never actually tested against the way the business works. And when this happens, it is not fun for anyone. You are in a production world now, with critical issues that have to be fixed quickly, and real projects, real clients, and real revenue at play. That is a hard place to be.
The teams that get this right treat UAT as an opportunity, not a hurdle. An opportunity to understand the system. An opportunity to understand their own process in a new light. An opportunity to find the gaps while there is still time to fix them without the pressure of live users and live data.
That shift in mindset, from “formality” to “opportunity,” is the difference between a go-live you celebrate and a go-live you survive.
The Part Nobody Wants to Talk About
UAT takes time. Real time. And the people best suited to do it are almost always the busiest people in your organization, the ones who understand the process deeply because they live in it every day.
I will not pretend this part is easy. Carving out dedicated UAT time on top of regular work feels nearly impossible. Almost every client I have ever worked with has hit this wall. It is not a sign that something is wrong with your team; it is the reality of running a business while simultaneously trying to improve it.
Here is what I tell every client: the time you invest in thorough UAT before go-live pays dividends on the other side. Every shortcut you take turns into a workaround your team has to remember for the next six months.
Every hour you skip in testing turns into two or three hours of post-go-live fire drills.
A few practical things that help:
Block the calendars. Not a vague “we will do testing that week,” but actual blocks of protected time on actual people’s calendars, with leadership backing it up.
Backfill where you can. If your best tester is also your busiest person, that is not a reason to skip them. It is a reason to give them coverage on their day job so they can actually test.
Make it visible. UAT progress should be tracked and reported like any other project milestone. Quiet UAT tends to become no UAT.
Leadership has to protect the time. If the CFO or head of Services is not publicly backing UAT as a priority, it will not happen. Testing loses to day job every time unless someone senior says otherwise.
What “Done” Looks Like
How do you know when UAT is actually complete?
Not when the calendar says you are out of time. Not when everyone is tired. Not when the project plan says testing ends on Friday.
Real UAT is complete when your team has validated the system against the work they actually do, identified the issues that need fixing, and made a deliberate decision about which issues are go-live blockers and which can be addressed after launch.
That last part matters. Not every issue is a go-live blocker. Some things can wait, especially if you are following the “keep it simple at go-live” principle I have written about before. The decision to defer an issue should be a deliberate one, not a default one. Someone should be looking at each open item and asking: is this a go-live blocker, or is this a backlog item for month three?
Signoff is not a signature on a form. It is a statement from the business that says: we have tested this, we understand what works and what does not, and we are ready to go live with eyes open.
When you get to that point, going live with minimal hiccups is genuinely something to celebrate. And the celebration is earned here, in the unglamorous work of testing, weeks before the go-live email ever gets sent.
Coming in Part Two
This article was about the why. Why UAT matters, why so many teams get it wrong, and what it actually means to do it well.
Part two is about the how. How to build test scenarios that reflect your actual work. How to test to your process, including the negative test cases that most teams skip. Who should write tests versus execute them. And what to do when UAT surfaces something unexpected.
If any of this resonated, I would love to hear about it in the comments. What has your UAT experience looked like? Where have you seen it go well, and where have you seen it fall apart?
See you in two weeks for part two.
Amy McFadzean is a PSA consultant and SuiteProjects Pro specialist with 20 years in professional services and over a decade helping organizations implement, optimize, and get real results from their PSA platforms. PS Playbook is where she shares what she has learned along the way.
If this resonated, subscribe for more practitioner-first perspectives on PSA, professional services operations, and making your systems actually work for you.