500+ hours per month recovered
The short version
Audited the manual data workflows of a government court system, identified where staff were double-entering data,
reconciling conflicting reports, and building workarounds to compensate for a case management system that wouldn't
give them back what they'd put into it — and fixed it.
---
The Problem
When I arrived, ongoing reporting across the organization was fragmented. Data lived in a case management system that
staff had painstakingly filled in — but couldn't get back out at the level of granularity they needed. So they'd built
workarounds. Elaborate Excel processes, pulling from multiple reports that didn't match each other, manually
reconciling the differences each month, and entering the same data in more than one place to keep everything
consistent.
My team didn't have direct access to the underlying data sources. The reports that existed had been built outside our
team and weren't sufficient. The gap between what the case management system held and what people could actually use
had been filled, entirely, by human labor.
---
What I Did
We started by sitting with the people doing the work. Not to audit them — to understand them. What were they pulling?
From where? What didn't match, and how were they deciding which number to trust each month? What had they built in
Excel, and why? What were they actually trying to know?
The workarounds people build when systems fail them are usually ingenious. They're also a map of exactly what's
broken.
One example that stuck with me: a team had essentially recreated their case management system's own data entry fields
in a parallel tracking document — because the options in the system had never been properly defined or cleaned up. We
brought everyone together to define what each option actually meant, removed options that were redundant or too
similar, and standardized what remained. Once the case management system reflected what people actually needed, we
could generate an ongoing report directly from it. The parallel document disappeared.
That pattern repeated across the organization. We'd find the workaround, trace it back to the underlying gap — a
definition problem, an access problem, a reporting problem — and close it. We built relationships with IT so we could
request the data access end-users needed. We did governance work — defining options, standardizing language, removing
ambiguity — so the system could be trusted. And we built the reports that let people manage their caseloads from one
place instead of five.
---
The Result
Over 560 staff hours per month recovered — 320+ from analytics automation and 240+ from process redesign — without
adding headcount, without restructuring teams, and without asking anyone to do their job differently in any way that
felt like a burden.
That last part surprised us. Going in, we worried that asking people to change how they entered data — to use
different options, stop using certain fields, standardize language they'd developed their own versions of — would meet
resistance. It didn't. People knew their workarounds were workarounds. They weren't attached to them. They were doing
the extra work as a means to an end, and when we offered a path to half the work with the same result, the response
was gratitude.
The lesson has stayed with me: change resistance is usually about adding friction, not changing direction. When you
remove friction instead — when what you're asking people to do is genuinely easier than what they were doing before —
the change manages itself.