Suppose the CEO opens the user acceptance testing (UAT) queue every evening to approve what the team fixes first. Routine fixes wait alongside decisions that affect the contract. For the first month, I’d choose one project, let the team make decisions within agreed limits, and check what happens to quality and workload as waiting time changes.
Days 1 through 7. Review recent work and assign decisions
Ask the project lead and the people who take the work forward to open the last 10 working days of UAT tickets. Focus on in-scope decisions about which fixes to prioritize. Record when the information was ready, who actually decided, and when the work could move. Keep open cases visible so you can see what the timing data for completed decisions leaves out.
Write a one-page agreement. The project lead can prioritize fixes within the existing budget and delivery date. Name a backup and the people the lead should consult. Leave changes to contract scope, risks to customer data, and changes to delivery dates with the people already authorized to handle them. Set aside time for the pilot by dropping one routine duty, such as a duplicate report that pulls data from the ticketing system.
Days 8 through 21. Run the pilot and review real cases
Use the agreement for the next 10 working days. Give the team access to the same evidence and record each decision in the original ticket. When someone flags a risk, the manager helps determine which decisions the team can still make and which need immediate escalation. Midway through, review one case that moved and one that’s still waiting. If you change the agreement, record when and why. The team is now testing a different arrangement.
I’m borrowing the idea of a small test from the Institute for Healthcare Improvement’s Model for Improvement. State what you expect, collect evidence, and decide what to do from what happens. The 30-day schedule and measures below are choices for this scenario. Institute for Healthcare Improvement, Testing Changes
Days 22 through 30. Read the results together before expanding
Use the same eligibility rules and follow-up periods in both rounds. Keep open cases visible and note changes in the work or go-live schedule that could make the rounds hard to compare. These numbers are hypothetical.
| Measure | Before the pilot | During the pilot |
|---|---|---|
| Median wait from information ready to decision, decided cases only | 16 working hours (20 cases) | 8 working hours (20 cases) |
| Cases escalated to the CEO out of all in-scope cases | 8 of 22 | 3 of 24 |
| Cases reopened within 5 working days out of closed cases with full follow-up | 2 of 18 | 4 of 17 |
| After-hours work the team logged for in-scope cases | 6 hours | 11 hours |
| Cases still awaiting a decision at the end of the period | 2 of 22 | 4 of 24 |
In this example, fewer cases reached the CEO and completed decisions took less time. Reopened cases, after-hours work, and undecided cases all increased. I’d hold off on expanding. Have the team look at which kinds of work led to reopened cases and extra hours, then adjust the decision boundaries or the time set aside before another trial. Ask the people doing the work whether they had enough information to decide and whether someone else picked up work that these measures missed.
On day 30, the CEO decides whether to continue, revise and retest, or stop. Record the reason, who owns the next step, and the next review date. If you could start with one decision this week, which one keeps waiting for you even though the team has enough evidence to make it?