Field note
Rework is a decision nobody made.
Most rework is not a build error. It is a requirement, a test or a handover that nobody decided to do properly.
Trevin Nimaladasa · Founder, Clariti · 2 Oct 2026 · 4 min read · Practice
When a system goes live and does not match what the business needed, the build takes the blame. The configuration was wrong, the SI missed the requirement, the vendor did not listen.
Sometimes that is true. More often the cause sits earlier, and it was a decision nobody made.
Where rework is born
A requirement that cannot be tested is not a requirement. It is a hope. It gets built, interpreted and signed off, and the disagreement about what it meant surfaces in UAT, when it is most expensive to resolve.
UAT that is scheduled but not designed is the same problem later. Testers are borrowed from their jobs for a fortnight, scenarios are improvised, and the defects they find are the ones the plan has no room for.
Nobody decides to build the wrong thing. They decide not to check, and the wrong thing is what is left.
Evidence, kept as you go
The remedy is not more process. It is a line of evidence kept current from the first requirement to cutover: what was asked for, what was designed, what was tested, and what the result was. When that line exists, a change is a visible decision with an owner. When it does not, change is absorbed quietly, and called rework later.
The same line makes go/no-go honest. If the criteria were set in advance and the evidence is on the table, the call is made on the facts. If not, it is made by whoever is most worried, or most tired.
What to do this week
Pick the ten requirements that matter most and ask how each would be tested. Name the people who will run UAT and check they are released from their day jobs. Ask who, other than one person, can run the cutover. Wherever the answer is nobody, a decision is waiting to be made.