1. Starting point and outputs
Who benefits
- Senior leaders and directors of planning and organizational development.
- Quality and excellence teams, and service and process owners.
- Internal consultants and performance improvement teams in ministries, authorities, and companies.
What you will produce
- A diagnostic charter defining the question, scope, and decision-making authority.
- A documented performance baseline with definitions that support repeat measurement.
- An evidence-backed cause map and a prioritized list of improvements.
- A package of interventions specifying the implementation owner, estimated cost, and method for verifying impact.
Inputs to prepare
- Approved mandates, strategy, and operational objectives.
- Transaction, complaint, and resource records for a period covering normal and peak operations.
- Process maps, policies, delegations of authority, and samples of actual case files.
- A stakeholder list, data access rights, and limits on the use of personal information.
2. Working methodology
From a symptom to a testable cause
Start with a statement describing a measurable observation: transactions in a specific category exceed the target completion time. Avoid jumping to statements such as poor employee performance or the need for a new system. Break the problem into hypotheses about process, capacity, authority, information, and demand. Each hypothesis needs evidence that supports it and evidence that could disprove it. Treat a cause as provisional until a comparison or direct observation supports it; two events occurring together do not, by themselves, establish causation.
Triangulating evidence and setting confidence limits
Combine an operational record, an interview, and direct observation of the transaction journey. Document the dates covered by the data, field definitions, and any missing days or system changes. When sources disagree, do not select the one that best fits the team's view; investigate and record the reason for the difference. Use a sample covering branches, channels, and case types, and state the limits on generalizing its findings. Interviews reveal possible explanations but do not replace measurement of the scale of the problem.
Diagnosis as a decision-making partnership
Form a small team comprising the service owner, an analyst, and a frontline representative, supported by a sponsor able to remove obstacles. Process owners should check the accuracy of facts without being given the right to delete uncomfortable findings. Present findings as a fact, an interpretation, and a decision required. Distinguish issues management can fix directly from those requiring a policy change or approval by another authority, while leaving final responsibility with the competent organization.
This is an adaptable practical approach developed by the Union with reference to the sources below. Adjust steps, timeframes and measures to the organization and its data. It is not a certificate of compliance or accreditation by the referenced organizations.
3. Implementation steps
1 Define the assignment and diagnostic boundaries
Hold a kickoff session to formulate one main question, such as: Why is the approvals service delayed? Define the service's start and end points, the branches and period included in the study, and any exclusions with their justification. Agree on the decisions the report will support, who will approve the findings, and who owns the data. Record potential conflicts of interest, confidentiality boundaries, and an escalation mechanism for missing information. Do not begin broad data collection before the scope is clear.
- Suggested owner
- Executive sponsor and diagnostic lead.
- Required output
- An approved project charter and stakeholder map.
- Progression check
- The problem, its scope, and the decision required can be explained in one paragraph.
2 Build a measurement dictionary and baseline
Define completed, returned, and suspended transactions, and the time to be counted, before extracting figures. Extract demand volume, completion time, errors, and backlog by channel and category. Distinguish staff working time from the time a file spends waiting. Check for duplicates and implausible timestamps, and reconcile the record count with the source total. Report the median and variation when cases differ; do not rely solely on an average that may conceal severe delays.
- Suggested owner
- Performance analyst and data officer.
- Required output
- A data dictionary and documented baseline dashboard.
- Progression check
- Another analyst can reproduce the calculation from the same source.
3 Trace the actual workflow
Select completed, delayed, and returned cases, then trace their progress from request to outcome. Map activities, acceptance decisions, and handoffs between departments, adding working and waiting time at each stage. Ask the person doing the work what happens when a document is missing or an authorized decision-maker is absent. Record informal routes and duplicate data copies, distinguishing them from the approved procedure. Do not assume that the map in the procedure manual reflects reality.
- Suggested owner
- Process analyst and representatives of the departments concerned.
- Required output
- A current-state map and a list of breakdown points.
- Progression check
- Staff who perform the work review the map, and case files or observations substantiate it.
4 Test hypotheses and causes
Link each bottleneck to specific hypotheses: re-entering data, conflicting delegations of authority, or unclear application requirements. Compare cases with the factor against similar cases without it, allowing for complexity and volume. Use successive why questions without turning them into accusations against individuals. Classify findings as sufficiently confirmed for action, likely, or requiring further data; record alternative explanations before selecting a solution.
- Suggested owner
- Diagnostic lead and process owner.
- Required output
- A register of causes, evidence, and confidence levels.
- Progression check
- Each cause has a clear link to evidence that can be reviewed.
5 Prioritize and define the intervention
Assess each opportunity by its impact on service users, frequency, the risks of leaving it unresolved, and feasibility. Use a simple published scale, such as scores from one to five, defining each score before assessment. Discuss the difference between a quick action and a fundamental fix on which other changes depend. Include maintaining the current situation as a comparison option, and explain the cost of delay and dependencies without inventing uncalculated savings.
- Suggested owner
- Steering committee, finance, and process owners.
- Required output
- A priority matrix and a justified package of interventions.
- Progression check
- A technologically attractive initiative does not take precedence over a higher-impact problem without explanation.
6 Design a limited improvement pilot
Identify a change that can be tested, such as a standard document checklist or delegation of a recurring decision within approved authority. Choose a suitable branch or transaction type, and set a pilot period that allows enough cases. Record success measures and safeguard measures, such as error and complaint rates. Specify who can stop the pilot and when the previous procedure will be restored if harm emerges. Tell employees what will change and how to record exceptions.
- Suggested owner
- Service owner and operations officer.
- Required output
- A pilot brief and a monitoring and rollback plan.
- Progression check
- The definition of success and the pilot risks are approved before launch.
7 Analyze results and decide whether to scale up
Compare results with the baseline, explaining differences in demand volume, case mix, and any concurrent changes. Use a suitable comparison group if one is available, without claiming it removes every external factor. Calculate improvements in time and quality together, and examine their effects on departments further along the workflow. Report case counts and missing data. Decide whether to scale up, adjust, or stop based on this evidence.
- Suggested owner
- Performance analyst and steering committee.
- Required output
- A pilot report and a reasoned management decision.
- Progression check
- An initiative is not declared successful on the basis of an impression or an exceptional week.
8 Embed the improvement and close the assignment
Update the procedure, forms, delegations of authority, and required training, and name an owner for each indicator. Establish a periodic review focused on deviations and corrective actions rather than simply displaying figures. Hand over data files, their dictionary, and the decision log to the internal team, and remove temporary access permissions. Close the assignment after outputs are accepted and owners and deadlines are set for outstanding items; finishing the report does not end responsibility for implementation.
- Suggested owner
- Development director and service owner.
- Required output
- A handover package, follow-up plan, and ongoing responsibilities.
- Progression check
- There is one current, authoritative version of the procedure and a named person responsible for every follow-up action.
Guide and editable templates: https://uhrda.net/en/organizations/guides/diagnosis/
4. Working templates
Review the illustrative row, then complete a copy of the blank row using your organization’s information. Download each template as CSV or print it within the guide.
Hypothesis and evidence register template
Complete this for each problem and update it when new evidence emerges. The first row is a hypothetical example; the next is provided for use.
| Problem | Hypothesis | Evidence required | Finding and confidence level | Next action |
|---|---|---|---|---|
| Delayed approvals | Files wait for a centralized signature | Arrival and signature times, and a review of delegated authority | Waiting observed in 18 of 30 cases; medium confidence | Test an approved alternative signing arrangement |
Improvement initiative brief
A short decision document linking the change to an owner and verification evidence; the figures are pilot targets, not a general commitment.
| Initiative | Responsible person | Baseline | Pilot target | Verification and safeguard measure |
|---|---|---|---|---|
| Standardize the document checklist | Customer service director | 20% of transactions returned | Fewer than 15% of transactions returned | Weekly review, with no increase in acceptance of incomplete files |
5. Hypothetical example: diagnosing delays in an approvals service
A hypothetical service authority noticed an increase in complaints, and management assumed staff shortages were responsible. A review of 200 transactions in one category found a median completion time of ten days and 40 transactions returned for missing documents. These are educational data and do not represent an actual organization.
- The team traced a sample of cases and discovered that requirement lists differed between two channels.
- It standardized the list and trained reception staff, then tested it on a later batch of comparable complexity.
- It monitored returned cases, incorrect rejections, and waiting time, and documented changes in demand during the pilot.
Interpreting the result
In the next hypothetical batch, 24 of 200 transactions were returned: 12% compared with 20%, a decrease of eight percentage points. The median fell to eight days. The result supports a decision on a larger pilot; it is insufficient on its own to prove that the change caused all the improvement.
Learning from the case
Good diagnosis tests operational causes before increasing resources and measures quality alongside speed.
6. Measures and follow-up
Agree each definition, data source, baseline, target and accountable owner before measurement. Targets require organizational approval. A zero denominator makes a ratio not calculable rather than zero.
| Measure | Calculation | Source | Review frequency |
|---|---|---|---|
| Median completion time | The middle value of completed transaction durations after sorting them; for an even number, use the average of the two middle values. Fix the measurement start and end points and the type of days counted. | Transaction register and approved timestamps. | Weekly, separating categories and channels. |
| Return rate | Number of unique transactions returned at least once ÷ total transactions examined in the same batch × 100. | Review register and reasons for return. | Weekly or monthly, depending on volume. |
| Compliance with the service deadline | Transactions completed within the approved duration ÷ all transactions completed during the period × 100; show the open-case backlog alongside it. | Request management system and service time standards. | Monthly. |
| On-time closure of improvement actions | Actions due during the period and closed with evidence on or before their deadline ÷ all actions due during the period × 100. | Initiative register and output acceptance records. | Monthly; show not applicable if no actions are due. |
7. Indicative implementation plan
The periods below are adaptable planning stages, not guaranteed delivery times.
| Period | Action | Deliverable |
|---|---|---|
| Phase one: a suggested two weeks | Confirm the scope, collect data, and map the workflow. | A charter, baseline, and operational map. |
| Phase two: a suggested two to four weeks | Test causes, design a pilot, and select its indicators. | An evidence register and approved pilot brief. |
| Phase three: a suggested four to eight weeks | Run the pilot, review results, and embed the appropriate change; adjust the duration to the service cycle. | A scaling decision, follow-up plan, and updated procedure. |
8. Common pitfalls
An overly broad assignment, such as developing the entire organization.
Divide the work into specific questions and services with separate acceptance criteria.
Turning interviews into judgments about individual performance.
Analyze the system and context first, and do not publish attributed statements without a need and authorization.
Improving the average while neglecting the longest cases.
Show the distribution of durations and the backlog, and separate complex cases.
Copying another organization's targets without allowing for service differences.
Base the target on the local baseline, capacity, and risks.
Closing a recommendation as soon as a circular is issued.
Require evidence of implementation, an assessment of its effect, and acceptance by the process owner.
9. Review checklist
- □ The scope and decision required are clear.
- □ Indicator definitions and sources are fixed.
- □ Causes are linked to evidence and confidence levels.
- □ The selected option is testable and has an owner.
- □ Quality measures guard against inappropriate acceleration.
- □ Working files and the follow-up plan have been handed over.
Use this checklist at the final review. Record observations, the decision owner, approval date and document version.
10. Further reading
Original practical material prepared for the Arab Union for Human Resources Development. Sources support the concepts and further reading; the illustrative models and cases belong to this guide. Reviewed: 16 October 2026.
- GOV.UK — How to set performance metrics for your service
A reference for linking metrics to the service's purpose and combining data with user research; the steps and templates here are original practical formulations.
- GOV.UK — Using performance data to improve your service
A reference for using performance data to select improvement opportunities. Requirements in the source apply to its UK government context and are not transferred to Arab organizations.