The Client's Priorities Flipped Mid-Engagement. We Still Found 5 More Points of Savings.

Every engagement in this series starts from a client's stated priorities, ranked. This client's original order, set at the very beginning, was straightforward: reduce cost first, keep the number of roles manageable second, and preserve how broadly people were already granted access a distant third. Once the first redesign batch was live and departments were actually working inside their new roles, that order changed, in substance, not just in emphasis: preserving access breadth moved to first place, role count stayed second, and cost, the reason the engagement existed in the first place, dropped to third.

That's not an inconsistency to manage around. It's a legitimate response to lived experience: once people have been through one round of change, the cost of revoking something without proof it's unused, a stalled process, a support ticket, a department that no longer trusts the next round, outweighs squeezing out further savings, at least until there's more confidence in the process. We took the new order at face value. The harder question was what it meant for the actual point of the engagement: this is a remediation project, and remediation projects exist because of a real bill. Deprioritizing cost doesn't make that bill smaller.

What the new priority order actually ruled out

With access breadth now the top priority, the lever behind our largest published savings, clustering people by what they actually do rather than by their current role, was off the table. That approach can put someone on a cheaper license entirely, but only by regrouping people across roles based on real usage, which is precisely the kind of change to "how things look" the client had just told us they wanted to avoid. So the design had to keep each role's core built around that role's own current population, trimming only what was clearly incidental. That's a real, different design philosophy from usage-clustering, and it's grounded in exactly what the new priority order asked for: a role stays recognizable as the job people already know.

The first comparison: 26% against 14%

Against the same modeled baseline, our usage-clustered design (still the right answer if cost were priority one) saves roughly 26%. The design built to the client's new order, keeping every role's shape, first came out at roughly 14%. A twelve-point gap, and on the surface it looked like the honest price of the new priorities: give up usage-based regrouping, give up a meaningful chunk of the savings.

We tested the trim threshold first. It didn't move the number.

Before accepting a twelve-point gap as final, we checked the most obvious remaining dial: how wide a slice of "rarely touched" access gets trimmed from each role. We swept it from the narrowest reasonable cut to a noticeably wider one. Savings barely moved, staying in a tight 13-14% band the entire way. That ruled out the trim threshold as the lever, without ruling out that a lever existed somewhere else.

The real lever: re-scoping how a role's own price gets built

The remaining question wasn't how much to trim, it was how each role's required license was being determined in the first place. As built, a role's price drew on everything its current members need across every role they hold, not on what that specific role, evaluated on its own, actually requires. Someone who mostly worked in one role but occasionally touched a second, pricier one was pulling that pricier tier into the first role's price too, purely because of what else that person happened to do elsewhere, not because of anything the first role itself demanded.

That's invisible in a usage-clustered design, roles there are already built from what people actually do, so the two ways of scoping a role's price rarely disagree. It's exactly the population a current-role-anchored design cares most about protecting where it matters: every role kept exactly as it already was, priced more accurately than it had been. So we re-scoped the model, deliberately, from pricing a role off a user's full footprint to pricing it strictly off that role's own evidence. Nothing about which roles exist, who holds them, or how wide their coverage is changed. What changed was the strategy behind the one number the client still needed to move: cost, now priority three, but never priority zero.

Re-priced this way, the design built to the client's new order recalculated at roughly 19%, not 14%, with meaningfully fewer people landing on a pricier seat than their own work in that specific role required. Five points of real savings were available inside the exact same role structure, the same coverage, the same headcount per role, the client had already told us mattered most. Nothing about their priority order had to be argued with to find it.

The remaining gap, 26% against 19%, is real, and it still comes from the same structural source: usage-clustering lets a person's tier follow their actual work, while a current-role-anchored design keeps each role at its own typical tier by definition. But a third of the gap we first reported wasn't a property of the client's priority order at all, it was a property of a pricing strategy we hadn't yet adapted to that order. Once we changed the strategy to match what they'd actually asked for, part of the "cost" of their new priorities turned out not to be a cost at all.

What we told them, and what we'd tell the next client

• A client's priorities can legitimately reorder mid-engagement, and the strategy has to reorder with them. "Cost first" and "coverage first" aren't the same project wearing different clothes. They call for different design philosophies, and pretending otherwise produces a design that quietly optimizes for the priority list you started with, not the one you're actually being asked to deliver against now.
• Deprioritizing cost doesn't waive it. This is a remediation engagement; a real bill is the reason it exists. When the top priority shifts away from cost, the job isn't to accept whatever savings fall out passively, it's to go find the savings that are still compatible with the new order.
• When the obvious lever is off the table, look for a different one before assuming the number is final. Usage-clustering was ruled out by the new priority order. The trim threshold turned out not to be the answer either. The actual lever was in how we were scoping each role's own price, a strategy question, not a tuning question, and it was still there to find.

Questions we get asked