Forty-One Percent Adoption
Five months ago a hospital rolled out a patient scheduling module. Targets: reduce no-shows from 18% to 10% and cut average phone booking time from six minutes to three. Actual no-shows are 16% and booking time is five minutes. Only 41% of bookings go through the module; 60% of clinics remain phone-only; several managers keep parallel paper lists. There are 210 open support tickets, most saying users cannot see provider availability across sites. The vendor says more training will fix it. Your internal IT analyst says the software is fine and staff are resisting change. Clinic managers say the module ignores their overbooking rules.
1. How should you measure and analyse the solution's performance?
Read the worked answer
Start from the measures the solution was meant to move, then segment until the aggregate numbers stop hiding the story.
- Compare actual to target: no-shows (16% vs 10%), booking time (5 vs 3 minutes), adoption (41%).
- Segment: by clinic, site, role and booking type. A 41% average almost certainly masks clinics at 90% and clinics at 5%.
- Quantify qualitative signals: support ticket categories, paper-list volume, and observed workarounds. Ticket themes are data, not complaints.
- Validate the data itself. How is the 41% counted, and are phone bookings that are later transcribed into the module counted twice?
- Add measures that reveal cause: percentage of bookings where cross-site availability was required, rate of overbooking-rule overrides, time spent on workarounds per clinic per week.
Then analyse rather than report: variance alone does not tell you whether the fault is the solution, the enterprise or the original value expectation.
2. Is the shortfall a solution limitation, an enterprise limitation, or a value gap? Justify your answer.
Read the worked answer
The evidence points to all three, in different proportions, which is exactly why the vendor's and the analyst's single-cause explanations are both inadequate.
- Solution limitation. Cannot-see-availability-across-sites is a functional gap, likely a missed or mis-specified requirement. Ignoring overbooking rules is a design defect against clinic practice. The module does not support the work, so staff route around it.
- Enterprise limitation. Sixty percent phone-only, parallel paper lists, training gaps and possibly clinic-level autonomy or incentives all sit outside the software. These are organisational constraints on realising value.
- Value gap. No-shows at 16% against a 10% target may indicate the original target assumed a capability the solution does not deliver, such as reminders or overbooking. That is a question about the business case, not just the product.
Diagnose before prescribing. More training addresses one cause; declaring staff resistant ignores a genuine design defect, and both would leave the 210 tickets open.
3. What corrective actions or design options would you recommend, and how would you decide between them?
Read the worked answer
Define options that map to the diagnosed causes, then compare them on value, cost, risk, time and fit with the hospital's architecture and clinic workflow.
- Option A, product fix: cross-site availability view plus configurable overbooking rules. Highest effort, addresses the root functional gap.
- Option B, process redesign: standardise booking workflow per clinic and remove paper lists by policy. Lower cost, depends on managerial authority and adoption.
- Option C, targeted training and champion support in low-adoption clinics only.
- Option D, hybrid: deliver Option A for the highest-volume clinics, pair it with Option B, defer the rest of the rollout until re-measurement.
Decide by evidence: the ticket distribution and clinic segmentation tell you where the functional gap bites hardest. Recommend the hybrid, with named success measures (adoption by clinic, no-show rate, booking time, ticket closure by category) and a review point, and record that solution evaluation feeds back into requirements and design rather than ending in a support queue.