Here's what usually happens when new software goes live.
The agency celebrates. The project sponsor celebrates. There's a launch announcement. Everyone pats themselves on the back.
Meanwhile, thirty people on the client's operations team are staring at a new system they didn't ask for, trying to figure out how to do their jobs with unfamiliar tools, missing the old shortcuts they'd spent years perfecting.
Six months later, adoption is at 40%. The sponsor is frustrated. The agency says "we delivered what was scoped." Technically true. Practically useless.
The missing metric is change burden.
Change burden is the real-world cost of adopting new software: the disruption to established workflows, the learning curve, the temporary productivity dip, the emotional resistance to doing things differently. It's not a bug -- it's an inevitable consequence of change. But if you don't measure it, you can't manage it.
At Vindico, we measure change burden alongside every project. During Discovery, we don't just ask "what features do you need?" We ask: who uses this system daily? What does their current workflow look like? How will this change disrupt their day? What training and support will they need? Where will we face resistance?
During the build, we design with adoption in mind. That means intuitive interfaces, familiar patterns where possible, and clear migration paths from old systems. It means involving end users in sprint demos, not just project sponsors.
After launch, we track adoption rates, training completion, support ticket volume, and user satisfaction -- not just system uptime and feature delivery. If a feature is technically perfect but nobody uses it, it's a failure. We'd rather know that early enough to fix it.
Change burden doesn't appear on most agencies' dashboards. It should. The most technically brilliant software in the world is worthless if the people who need to use it can't -- or won't.