Performance measurement
How Do You Know an IT Request Process Has Actually Improved?
Your IT team closes requests faster after introducing a new intake form. Is the process better? Perhaps. But faster closure alone does not tell you whether employees received usable access, whether requests were reopened, or whether difficult work is accumulating outside the reported queue.
Before choosing a dashboard, agree on the decision the measures should support: should the new workflow continue, change, or stop? The following approach is a suggested measurement plan for a small operational pilot. It can also be adapted to purchasing, onboarding, or internal service requests.
Write the improvement question first
Define the request type, the people served, and the intended improvement. For example: Can we reduce the time employees wait for standard software access while maintaining correct approvals and avoiding extra support work? Keep required security and authorization checks in place throughout the pilot.
Choose one reasonably consistent request category. Mixing a routine access request with a complex system implementation makes a single completion-time measure hard to interpret. Record changes in request mix or staffing alongside the numbers.
Choose measures that answer different questions
The Institute for Healthcare Improvement distinguishes outcome, process, and balancing measures in its improvement guidance. Outcomes describe the result, process measures examine whether intended steps occur, and balancing measures look for problems created elsewhere. The business example below adapts that distinction; it is not an IT standard or a prescribed universal scorecard.
- Outcome: How long does the requester wait for usable, approved access?
- Process: What share of submitted requests contain the information needed for assessment on the first review?
- Balancing: What share of completed requests require correction or reopening within a defined follow-up window?
- Unfinished work: How many open requests exceed the agreed age threshold?
The fourth measure is a practical safeguard for this pilot. Reviewing only completed requests can leave a team looking successful while older requests remain unresolved.
Create a definition card for every measure
A measure needs enough detail that two people can calculate it consistently. Use a shared note with these fields:
- Purpose: Which decision will this measure inform?
- Population: Which request categories, channels, and dates are included? Record exclusions and their reasons.
- Calculation: Specify the numerator and denominator for a percentage, or the exact start and finish events for elapsed time.
- Clock: State whether time means calendar hours or business hours. Define weekends, holidays, and any pauses.
- Data source and owner: Identify the system fields and the person responsible for checking them.
- Review rule: Agree when to review, what would trigger investigation, and who can authorize a change.
For waiting time, start at the original submission rather than silently restarting the clock when an incomplete request is corrected. Track time awaiting requester information separately if it helps diagnosis. This preserves visibility into the employee's full wait while distinguishing the reasons for it.
Illustrative example: a software-access pilot
Consider a fictional business testing a revised intake form. These numbers demonstrate calculations only; they are not ADH client results or recommended targets.
During one review period, 20 eligible requests receive their first assessment. Fifteen contain all required information, so first-review completeness is 15 divided by 20, or 75%. Count requests once, even if the reviewer asks several follow-up questions.
Separately, 12 completed requests have reached the end of a seven-day follow-up window. Two required correction, giving a correction rate of 2 divided by 12, or about 17%. Five more recently completed requests have not yet finished that window. Show them as awaiting follow-up rather than treating them as correction-free.
For elapsed time, report the median and longest wait among completed eligible requests, together with the number completed. Also show the count and age of still-open items. With a small sample, inspect individual delayed cases before attributing a change to the new form.
Collect a comparable baseline and review exceptions
Apply the same definitions to a recent period before the change if trustworthy records exist. If timestamps or closure criteria are unreliable, begin prospective collection and acknowledge the missing baseline. Do not reconstruct precise historical waits from memory.
Plot the measures by review period and annotate the pilot start, staffing changes, outages, or unusual demand. A better week is a reason to investigate, not proof that the workflow caused improvement. Read a few actual request histories with the people doing the work to understand what the numbers omit.
If completion gets faster but corrections increase, examine whether requests are closing before access is verified. If completeness improves but total waiting time rises, inspect approval queues and capacity. Review handoff acceptance and ownership when work is sitting between teams.
Turn the review into a decision
Before starting, agree which conditions would pause expansion, including any failure of required authorization checks. At each review, record whether to continue collecting data, adjust one part of the workflow, expand cautiously, or stop. Explain the evidence and uncertainties in a decision log.
Start this week by selecting one request category and writing its measurement definitions with an IT representative and a requester. Confirm that the necessary timestamps and follow-up information can be collected without adding disproportionate work. A small, consistently defined set of measures is a useful starting point for deciding what to improve next.
ADH Enterprises supports IT workflow improvement and performance measurement. Start a conversation about evaluating a process change in your organization.