A customer’s warehouse is about to test an ERP release. One tester finds a mislabeled button. Another finds that the system will accept a shipment with a quantity higher than the approved order. In this hypothetical project, both issues land in a chat where everyone can comment and nobody knows who can authorize a fix or stop the release.
A useful decision rule gives the people closest to the work room to act and tells them where their authority ends.
Give each decision a name
The project manager can keep the list moving while the relevant owner makes the call. In this example, decisions about test scope, business controls, and the date committed to the customer require different authority. Agree on these roles with the customer before user acceptance testing (UAT).
| Situation in UAT | Who makes the call | What the team needs to show |
|---|---|---|
| A confusing button label with no effect on the transaction | Delivery lead can approve the wording change within the agreed scope | Before-and-after text and a focused retest |
| A shipment can exceed the quantity authorized by the order | Customer’s warehouse process owner decides whether the business rule and fix are acceptable. The release lead holds the affected workflow until it passes retest | Test record, affected transaction, proposed control and retest result |
| The fix would move the date promised to the customer | Project sponsor decides on the commercial commitment within delegated authority. Escalate to the CEO if it exceeds the sponsor’s mandate | Options, risk, estimated impact on the date, and a recommendation |
For the shipment problem, the delivery lead can start reproducing it and preparing a fix. A second person can handle the work if the lead is away. The warehouse process owner still decides whether the corrected rule matches how the business operates. This keeps progress visible without leaving release authority to whoever happens to be in the chat.
The distinction matters beyond software. In a field experiment with Indian textile firms, Bloom and colleagues describe how better management information helped owners delegate more decisions to plant managers. That study is about textile firms. For an ERP project, it gives us a concrete question to ask. What evidence would let the person closest to the problem make a good decision? Supaket’s article on the Bloom study
Try it on a decision already waiting
Take an open UAT issue and write down the decision in one sentence. Choose an owner and a backup. Write one observable escalation condition, such as a change to the date promised to the customer. Include the evidence the owner needs and how to reach the sponsor when the condition is met. Record the decision where the people implementing and testing it can see it.
For the next UAT cycle, start the decision clock when the evidence is ready and stop it when the decision is recorded. Compare waiting time for similar issues and count escalations out of all decisions in each category. Review any reopened issues or decisions reversed after a missed control. If fewer issues reach the sponsor and more fixes are reversed, examine where the decision rule gave the owner too little information or too much latitude.