Worked example: mandated enterprise software
This is an illustrative composite that shows the method. It does not describe a real system and it makes no claim about clinical outcomes.
The situation
A hospital system’s chief information officer bought a documentation tool for several thousand clinicians. The organization requires its use. Every clinician logs in daily. The dashboard is green.
What the login count cannot show
The chapter “The Buyer and the User Are Often Different People” gives the rule: when a person has little or no practical choice about using a system, usage alone cannot prove the product earned acceptance.
Actor map
| Role | Buys | Can mandate | Uses daily | Can abandon |
|---|---|---|---|---|
Chief information officer |
Yes |
Yes |
No |
No |
Chief medical officer |
No |
Yes |
No |
No |
Unit nurse manager |
No |
Partly |
Sometimes |
No |
Clinician |
No |
No |
Yes |
Only by working around it |
Patient |
No |
No |
No |
Affected |
The test design
-
Observe workarounds, not logins. Shadow twenty clinicians across shifts in three units. Record every use of paper, a personal app, a copied template, or a second person’s help. Use the observer guide.
-
Time the task. Time a standard note from the first click to the signed note, under real interruptions.
-
Measure after-hours work. Where records allow, count documentation done after a shift ends. Treat it as a signal to investigate and not as a verdict.
-
Ask about choice. In interviews, ask “If nobody required it, would you use it?”
-
Compare. Where a unit has an alternative approved tool, compare it, with the caveat that the units differ.
Competing explanations to write down first
-
The units observed were the ones that volunteered.
-
Clinicians behave differently when observed.
-
Workarounds existed before the tool.
-
The tool is fine and the workflow around it is the problem, which the team may still need to fix.
What the decision could be
Change the workflow, change onboarding, change the configuration, ask the vendor for changes, or keep it as is with a recorded reason. The chapter “Teams Misread Acceptance Evidence in Fourteen Predictable Ways” lists what to avoid: coerced-usage bias and buyer-user confusion most of all.
Limits
Usability and workflow acceptance are not clinical outcomes. Nothing in this test shows that patient care was better or worse.