The UAT That Saves You Three Months of Firefighting
- 2 days ago
- 5 min read
Real UAT is not a task you rush through. It is your best chance to walk into go-live with confidence instead of hope.
I flagged this in an earlier piece on why implementations fail, and it is worth saying again. UAT is not optional. I mean real UAT, not the version where a few people click through the system for an hour, nothing obviously breaks, and everyone calls it done.
That is not testing. That is hoping.
What real testing looks like
Real UAT means testing to your process, not just testing that the system technically functions. Those are two different things, and the gap between them is where most implementations come undone.
A system can work perfectly and still fail your team, if what it does is not what your team actually needs it to do. Clicking through a few screens tells you the buttons work. It does not tell you whether your project setup handles the way your services team actually structures engagements, whether your billing rules hold up against the way your finance team actually recognizes revenue, or whether the reports your leadership expects on day one come out the way they expect them to.
A system can work perfectly and still fail your team.
To test for real you need three things: your process documented, your team aligned on what that process actually is, and test scenarios built directly from the work your team does every day. Not hypothetical scenarios. Not the vendor's example workflows. Yours.
What a real scenario looks like next to a fake one
This is the difference that decides whether UAT was worth doing, so it is worth making concrete.
The click-around version: "Create a project. Add a resource. Log time. Run a report."
Every one of those steps will pass. None of them tell you anything, because none of them resemble your actual work.
The real version: "Create a fixed-fee project for a client with a three-phase statement of work. Staff it with two roles at different bill rates. Log time against phase two, including one entry that should be non-billable. Submit it late, the way people actually submit it. Approve it. Now confirm the invoice reflects the fixed-fee terms and not the hours, and that revenue recognition lands where finance expects it to."
That scenario can fail in six different places, and every one of those failures is something you would otherwise have found in production, with a real client on the other end of it.
The test is not whether the software works. The test is whether your business runs through it.
Who should actually be in the room
The other thing teams get wrong is who does the testing.
UAT often lands with the project team, because they are the ones who have been closest to the build. They are also the worst people to test it, because they know how it is supposed to work. They will unconsciously navigate around the rough edges, and they will not notice the assumption that only makes sense if you sat in the design sessions.
The people who should test it are the people who will use it every day. The project coordinator who sets up twenty engagements a month. The billing specialist who will find the edge case in your invoicing rules within about four minutes. The consultant who enters time on a Friday afternoon and will tell you exactly what makes that painful.
They will find things the project team cannot see. That is the entire point.
Why teams skip this
I understand why it happens. By the time you reach UAT everyone is tired. The implementation has taken months, the go-live date is circled on the calendar, and testing feels like the thing standing between your team and being done. So it gets compressed into whatever time is left, instead of being planned for from the start. If you are earlier in that journey, the leap from spreadsheets to a live PSA system covers what the whole transition asks of you.
There is also a false sense of security that creeps in. The system looks right. It feels close enough. And "close enough" is a dangerous phrase to carry into go-live, because the gaps you do not catch in testing do not disappear. They wait for you, usually at the worst possible moment, in front of the worst possible audience.
What it costs you later
I have watched teams go live on a system that technically worked and still spend the first three months firefighting, because the scenarios that mattered most to their business were never tested. Revenue recognition that did not calculate the way finance expected. Reporting that leadership assumed would look one way and did not. Project creation workflows that made sense on paper and fell apart the first time a real, messy project moved through them.
None of that is a software problem. It is a testing problem, and it is almost always preventable.
The time you invest in real UAT before go-live is time you do not spend firefighting after it.
That trade is always worth making, even when it does not feel like it in the moment.
How to know when you are actually done
"We finished testing" is not an exit criterion. Before you sign off, you want to be able to say yes to all four of these:
Every core process has been run end to end by the person who owns it. Not demonstrated to them. Run by them.
Every failure has an owner and a decision. Fixed before go-live, fixed after, or accepted as a known limitation. Accepted is a legitimate answer. Undecided is not.
Finance has seen real numbers come out the other end. Not sample data. A scenario that mirrors a real engagement, all the way through to the invoice and the revenue.
Someone has tested the messy version. The late timesheet, the mid-project scope change, the client who gets billed differently from everyone else. Clean-path testing passes every time and proves nothing.
If you cannot say yes to all four, you have not finished testing. You have run out of time, which is a different thing, and it is worth naming the difference out loud before you go live rather than after.
Where to start
If you are heading into UAT soon, the first question worth asking your team is simple: are we testing our process, or are we testing that the system opens and closes correctly?
If you are not confident in the answer, that is exactly where to start. And if the answer is that nobody has built the scenarios yet, that is the work, not a reason to postpone it.
Want the scenarios already built?
UAT Essentials is the toolkit version of everything above: a testing guide plus a full test case spreadsheet, so your team starts from real scenarios instead of a blank page. Built from SuiteProjects Pro implementations, and the scenarios translate to any PSA platform, because you are testing your process, not the software.
Prefer to build your own? PS Playbook members get the UAT Scenario Workbook, a lighter walkthrough for writing scenarios from your own process.
Heading into UAT and want it done properly?
Testing to your process rather than to the software is most of what separates a calm go-live from three months of firefighting. If you want help building the scenarios that actually matter for your business, let's talk.
