Why UAT Spreadsheets Fail: The Four-Week Lifecycle of Every Test Tracker
Somewhere right now, an ERP go-live is being approved based on a spreadsheet that was last updated nine days ago. Nobody in the room knows if the pass rates are real. Nobody knows which defects are still open. Everybody signs anyway, because the date was booked months ago. This article is about how that spreadsheet got there.
The Tracker With 14 Tabs
Picture the UAT tracker on a typical ERP implementation. It has 14 tabs. Three people understand how it works. One of them is on holiday, one left the project in March, and the third one is you.
This is not an exaggeration for effect. It is how most mid-market ERP implementations track the single most important validation phase before go-live. Not because spreadsheets are good at the job, but because nobody ever gave the project team anything better. Excel is already open. The template from the last project is on SharePoint. UAT starts Monday.
What happens next follows a lifecycle so predictable you can set your project plan by it.
The Four-Week Lifecycle
Week 1: Pristine
The tracker is beautiful. Colour-coded status columns. Data validation on every dropdown. Conditional formatting that turns rows green when a test passes. A summary tab with a pie chart. Whoever built it is quietly proud, and rightly so. It represents real effort and real intent.
Week 2: Patched
Someone pastes over the formulas. The pie chart now reads 240% complete. A tester adds a column called "Notes 2" because the notes column was protected. Two people have the file open at once and one of them wins. The version on SharePoint and the version attached to Tuesday's email are no longer the same file.
Week 3: Duplicated
Three copies now exist. All of them are called FINAL. One lives on SharePoint, one on the project manager's desktop, and the newest one is attached to an email chain that only four people received. On one real project, merging the copies took a two-hour call, line by line, and twelve tests had different results in different versions. Nobody had done anything wrong. That is simply what happens when your source of truth is a file.
Week 4: Abandoned
Test results are now collected verbally in the Monday call. "Sales order processing? Yeah, we're basically done with that." The tracker gets updated from memory, by one person, after the meeting. The status report to the steering committee is green, because the tracker says so, because someone remembered it that way.
Go-Live: Forgotten
The spreadsheet is quietly never opened again. Until something breaks in production and someone asks whether it was tested. Then the archaeology begins.
Every consultant who has run an ERP project has lived some version of this. The important part is what it is not: it is not a discipline problem. The people involved are competent and trying hard. It is a tooling problem. A spreadsheet is a document pretending to be a system, and the pretence collapses under the weight of a real project.
Why It Always Ends This Way
Four structural reasons, none of which can be fixed with a better template.
1. A file cannot be a source of truth
The moment a spreadsheet is emailed, it forks. Every attachment is a new branch of reality, and there is no merge process. Cloud co-editing helps until someone takes a copy "to work on offline", which someone always does. Systems have one current state. Files have as many states as there are copies.
2. Nothing is assigned, so everything is optional
A row in a spreadsheet does not chase anyone. Testers with day jobs open a 40-tab workbook, cannot immediately see which tests are theirs, and close it again. The consultant becomes a full-time spreadsheet chaser: "Hi both, just chasing the test tracker again." Coverage gaps stay invisible until someone manually audits the file, which nobody has time to do.
3. Defects become rumours
A defect logged in a spreadsheet has no link to the test that found it, no history of who fixed what, and no proof it was retested. When the fix goes in, the row turns green and the connection is lost. If the fix quietly breaks a different scenario, and fixes to posting routines often do, nothing in the file will ever tell you.
4. The evidence evaporates
Sign-off should be a decision based on evidence: what was tested, what passed, what risks remain. A spreadsheet's evidence is a Last Modified date and a set of cells anyone could have typed anything into. Six months later, when an auditor or an unhappy client asks "who tested this and when?", the honest answer is a shrug.
What It Actually Costs
The costs are not hypothetical. Two examples from real projects, names removed.
Row 214
Go-live weekend on an ERP implementation. The finance team starts posting invoices, and VAT calculates wrong for one customer group. The test for exactly that scenario existed. It was row 214 of the tracker, marked "TBC" since June. Nobody was assigned to it, nobody chased it, and nobody knew. Row 214 cost three weeks of corrections and a very uncomfortable client meeting.
19 of 31
On another project, hypercare week one produced 31 support tickets. A retrospective review found that 19 of them related to scenarios a written test case already existed for. The tests were simply never executed, and nobody knew, because "executed" lived in people's heads and a file nobody trusted. Most hypercare pain is not new defects. It is untested scope being discovered by the client's customers.
Untracked tests are untested tests. That is the whole failure mode in one sentence.
What Good Looks Like
None of this requires enterprise tooling or a change management programme. It requires five properties that a file cannot provide and any purpose-built system should:
- One current state. Everyone looks at the same live data. There is no FINAL_v7_USE_THIS.
- Named assignment. Every tester sees exactly their tests, in plain language, with a pass/fail button. The "engagement problem" mostly disappears when people can see what is theirs.
- Linked defects. Every defect connects to its test case, its fix, and its retest result. "Is that bug fixed?" becomes a click, not an investigation.
- Visible coverage. Row 214 cannot hide. Unexecuted tests are loud, not silent.
- An audit trail. Who ran what, when, and what happened. Sign-off becomes evidence, not theatre.
An Honest Caveat
If you are running a two-week UAT with four testers and thirty test cases, a well-managed spreadsheet with one strict owner can survive. Plenty have. The lifecycle above accelerates with scale: more testers, more test cases, more than one project running at once, or a client sign-off that needs to stand up to scrutiny later.
The moment you recognise week two or three from your current project, the file has already forked and the pie chart is already lying. That is the moment to move, and your existing spreadsheets are not wasted work: the years of test scripts you have built up are the asset. The spreadsheet was just a bad container for them.
The Bottom Line
UAT spreadsheets do not fail because project teams are careless. They fail because a file cannot do the job of a system: it forks, it hides gaps, it turns defects into rumours, and it produces sign-offs nobody can verify. The decay is structural and it follows the same four weeks on almost every project.
Your Next UAT. Not on a Spreadsheet.
LogicHive replaces the tracker with structured test cases, named assignment, linked defect tracking, and sign-off reports built from real execution data. Import your existing spreadsheets and keep the scripts, not the chaos. The free plan runs a real project end to end: 1 project, 3 testers, no credit card.
Written by Reece Hallam
Sales Director
Reece brings over 15 years of experience in ERP implementations, specialising in Business Central and Dynamics 365. He has led UAT programmes for mid-market manufacturing and distribution clients across the UK and Europe.
View all articles by Reece Hallam