Operational Performance Analysis: From Measures to Root Causes

Operational performance analysis examines how a process produces its results and what explains the gap between required and actual performance. Replace “the team is slow” with a specific question: why were service requests due this week not completed on time? This identifies the outcome, period and population to investigate without assuming the cause.

Choose a Key Performance Indicator (KPI) linked to a clear objective. On-time completion may be more useful than transaction count alone. Pair it with a quality measure, such as the proportion returned for correction, so that speed does not improve at the expense of accuracy. An indicator should support a decision, rather than merely add a coloured number to a report.

Suppose a service unit starts the day with 80 open requests, receives 120 and closes 100. Assuming no cancellations or reopened cases, its closing balance is 100 requests: 80 + 120 − 100 = 100. Completing more work than on a previous day is not enough to demonstrate improvement. Here, the backlog increased by 20 requests.

To measure on-time performance, suppose 100 requests were due during the week and 82 were completed by their deadlines. The result is 82%. The denominator includes every request due within scope, including overdue requests still open. Calculating the percentage from closed requests alone may conceal unfinished work. These are illustrative assumptions, not client results or universal performance benchmarks.

Transaction review shows that many requests wait for approval after processing is complete. Approval delay becomes a hypothesis worth testing. Examine sending, receipt and approval times, approver availability and reasons for returning requests. A queue before approval does not establish it as the only cause: work might arrive incomplete or in large batches.

Root Cause Analysis (RCA) helps explain a problem and select an appropriate response. A fishbone diagram organizes possible causes, while a Pareto chart ranks categories by a defined frequency or impact. These tools organize the investigation. An idea does not become a fact simply because the team agrees to place it on a diagram.

For each hypothesis, state what you would expect to observe if it were correct and what evidence would test it. In the approval example, trial a backup approver within authorized limits and compare waiting times for similar cases before and after the trial. Track changes in demand, complexity and any simultaneous adjustments. Improvement supports the hypothesis to the extent that the test is sound; it does not automatically rule out other causes.

When suitable sequential data is available, control charts help monitor variation over time. NIST’s handbook explains their use of statistical limits and patterns that warrant investigation. Do not confuse control limits with service targets or customer acceptance limits. A process can be statistically stable yet fail to deliver the required service. Chart selection and interpretation must reflect the data type and collection method.

Assign an action owner, review date, success criteria and conditions for stopping or changing the trial. If on-time performance rises from 82% to 90% in an appropriate comparison period, the increase is 8 percentage points. Examine approval errors, rework and complaints alongside it rather than declaring success from the speed measure alone.

For cost, distinguish released working hours from realized financial savings. Saving an hour of an employee’s time does not automatically reduce payroll. The benefit might instead be capacity for additional service. Record the calculation method and avoid counting the same benefit once as lower cost and again as additional production without explaining the relationship.