Handoffs, Rework and First-Time-Right
In one sentence
A request being completed in the end does not show that it was completed right the first time; follow returned requests under a single identity and calculate the quality loss and the extra workload separately.
By the end of this lesson
- Calculate first-time-right as 75% when 6 of 24 requests return.
- Separate the number of unique returned requests from the number of rework events.
- Calculate the extra effort and the responsibility handoffs that come from repeat work.
- Choose the right denominator for new requests, final acceptance and first-time-right results.
Why it matters
In an administrative process the output can be made right in the end, but that result may have been reached after many corrections and handoffs. First-time-right is the share of requests that meet the defined acceptance condition without returning for completion of missing information or correction of an error. The final acceptance rate counts the outputs accepted at the end of the period. The two indicators are different. Even if all requests are closed in the end, returns consume resources and delay the service. For this reason, looking only at the number of closed jobs leaves the information and processing quality problems of the first submission invisible.
A handoff is a change in the role responsible for the next work on a request. Not every handoff is an error; separation of expertise and authority can create necessary handoffs. Even so, if information is passed on incompletely, the next role asks the same questions again, collects the data again or sends the work back to the previous role. It must be shown which information gap these events arose from. Making the number of message copies the handoff count is not enough, and neither is explaining the load by the number of people alone. The measurement rests on who accepted the work with what information and for what reason they returned it afterwards.
Rework is the need to correct or repeat work already done in order to reach the acceptance condition. The same request can return more than once. For this reason the number of unique returned requests and the number of return events are kept separate. In first-time-right each request is evaluated once; in the extra workload calculation all correction events are taken into account. A later change in a valid customer wish should also be recorded, but it is not automatically counted as a process error. Whether the change is a correction of the first request or a new need that changes the scope is separated by a rule set in advance.
In this lesson, when 6 of 24 requests return, 18 requests are accepted as first-time-right and the result is 75%. Although the calculation looks easy, the real decision is to protect the denominator. A resubmitted document is not a new customer request. Counting repeats as new entries changes both the request rate and the capacity interpretation. Improvement should reduce the causes of returns at their source rather than hide the returns. Counting the error that a check caught as the fault of the check and removing the inspection is not a solution either; the point where the error was produced and the point where it was found are shown separately on the map.
Formula
First-time-right (%) = Requests accepted without returning ÷ Unique requests × 100
Return rate (%) = Unique returned requests ÷ Unique requests × 100
Extra effort (person·min) = Correction events × Effort per event
Average handoffs (handoffs/request) = Total handoffs ÷ Unique requests
Unlock the rest of this lesson with an Academy account
Create a free Academy account with your work email address; it can be used once it is approved.
- Step-by-step instructions
- Worked example with real numbers
- Where the method misleads
- Common mistakes