A client tests an inventory report and finds that reserved items are being counted as available for sale. A developer estimates a three-hour fix, and the project manager has other tests that can go ahead. But the team usually asks the CEO whether to fix the issue first or move the test. The CEO is in meetings, so a decision the project team could make sits until the next day.
The previous article covered Bloom and colleagues’ experiment in Indian textile mills. The researchers found that changes in management practices gave owners information they could use to delegate some decisions to plant managers. I’ll apply that idea to a hypothetical software company and ERP consultancy during user acceptance testing, or UAT. The textile findings come from an experiment in that setting. The figures below illustrate how an ERP project could evaluate its own process. Previous article on management in Indian textile mills · Bloom and colleagues’ study, Section V
Collect the information someone needs to decide
When logging a UAT issue, capture the test case, expected result, actual result, steps to reproduce it, and evidence from the test environment, such as a screenshot with client data redacted. For the inventory report above, the project manager also needs to know whether the report is in scope, which tests are blocked, and how long the team estimates the fix will take.
Keep the existing tracker as the source of record. That could be a task in Odoo Project or a shared spreadsheet. Add only what helps choose the next step, such as issue type, owner, which test is blocked, and when the evidence was ready for a decision. Once someone decides, record who made the decision, why, what happens next, and when the decision was made. For escalations, record which threshold was met. The same record can support daily follow-up and later review.
Write down who can make each decision
Before the pilot, have the CEO, project manager, technical lead, and client representative agree on the boundaries in one place. In this example, the project manager can approve in-scope fixes estimated at four hours or less per issue, within reserved capacity, as long as they leave the delivery date, price, and acceptance criteria intact. Name a decision owner and backup for each role. These thresholds are illustrative. A real team should set them according to its contract and capacity.
| Situation | Decision owner and authority |
|---|---|
| The report shows reserved inventory incorrectly, the fix takes an estimated three hours, and the delivery date holds | The project manager prioritizes and authorizes the fix. The technical lead chooses the implementation. A designated client user retests it. |
| Retesting passes and the work is ready for customer acceptance, or a production release is coming up | The client’s authorized representative signs off on acceptance under the contract. The release owner authorizes the production change through the release process. The project manager gathers evidence and coordinates timing. |
| The client asks for a new report broken down by branch, outside the original scope | The project manager documents the effect on hours, price, and schedule. Authorized representatives on both sides approve the scope change before work begins. |
| The work requires a production data change or expanded access, or client data appears in UAT | Pause the affected work and route it to the data owner or security lead under the project’s procedure. The project manager logs the status without copying sensitive data into the ticket. |
| An in-scope issue exceeds four hours or requires people assigned to another project | Ask the delivery lead to allocate resources. Escalate to the CEO when the decision exceeds delegated authority, such as approving an exceptional discount, changing a contractual commitment, or resolving a staffing conflict the delivery lead can’t settle. |
When several tickets share a cause, combine their estimated effort before applying the limit. That keeps several small tickets from quietly consuming more capacity than the team can spare. The project manager and technical lead review the queue daily. Send critical blockers and issues that meet a data escalation threshold as soon as they’re identified.
Check whether fewer issues reach the CEO and work keeps moving
Start with one project. Use two weeks before the change as the baseline, then pilot the new decision rights for two weeks on comparable UAT work. Count one decision per issue, even when it generates several follow-ups, and include requests for a CEO decision made in chat or in meetings. Define routine decisions up front as in-scope UAT issues that qualify for team-level decisions under the same criteria in both periods. Exclude mandatory CEO escalations from that denominator and track them separately. Log updates sent for awareness separately as well, so the CEO can still see how work is progressing.
| Measure | Two-week baseline | Two-week pilot |
|---|---|---|
| Routine decisions eligible for team ownership under the same criteria | 40 | 44 |
| Routine CEO escalations per 10 eligible decisions | 3.0 (12 of 40) | 1.1 (5 of 44) |
| Issues requiring CEO escalation that were actually escalated | 3 of 3 | 4 of 4 |
| CEO time spent on all UAT decisions | 6 hours | 3 hours |
| Median routine decision time from evidence ready to decision | 18 business hours | 7 business hours |
| Issues reopened within five business days of closure, among those with full follow-up | 3 of 28 | 3 of 34 |
| Total team time logged for triage, coordination, and decision records | 10 hours | 12 hours |
The numbers are hypothetical. If a pilot looked like this, I’d review the five routine cases that still reached the CEO and find out why the team couldn’t resolve them. I’d check that mandatory escalations reached the CEO and sample team decisions for adequate evidence, successful retesting where applicable, and the result promised to the client. Talk to the people doing the work and compare a sample of tickets with chat threads to look for issues kept quiet to protect the metric. The CEO spent less time, while the team spent two extra hours on triage and coordination. Ask how much of that time improved decisions and how much went into recording the same thing twice.
Issue complexity, staffing, and proximity to the delivery date can all change between periods. Check the open queue and how long unresolved items have been waiting, since the median uses completed decisions and the reopen count uses cases with full follow-up. If fewer issues reach the CEO while the team waits longer for someone else’s approval or critical cases sit unresolved, adjust the decision rights or escalation process before extending the pilot.
Before the next UAT cycle, pick one question the CEO gets repeatedly. Write down what evidence the team needs, who can decide, and when to escalate. In the next cycle, see who resolves that kind of issue and how long it takes.