The Client Chose Manageable Over Optimal. Here's the Number They Actually Paid For It.

Last time, we landed on a mathematically clean role-mining design for a client who'd rejected our original hundred-role license fix: zero users over-licensed, real evidence behind every grant, roughly $47,000 a month, down from a $72,000 baseline. It also came to roughly 760 roles and duties. We knew before we presented it that this was going to be the actual conversation.

It was. The client's answer arrived almost immediately: as few roles as possible, both the shared core roles and the smaller add-ons on top, and they told us upfront they were willing to pay more per month for it. Not "we'll consider a tradeoff if you show us one," a stated preference, before they'd seen a single alternative number.

What actually had to change under the hood

The cheapest design's own core rule, that no shared role is ever allowed to grant even one member more than their evidence supports, was precisely what was blocking further consolidation. A role that's a near-perfect fit for 95% of its members but slightly over-grants the remaining 5% gets rejected outright under that rule, no matter how close it is. Consolidating further meant deliberately relaxing that rule, on purpose, with the client's own informed consent, not discovering it as an accident later.

We rebuilt the mining pass around a looser, more forgiving version: one core role per job family regardless of license tier, a privilege joins that core if a clear majority of the role's members genuinely need it, and a modest, capped amount of over-provisioning is accepted as the price of fewer objects. We also added a second pass purely aimed at merging near-duplicate add-ons that were nearly identical in what they granted, and a small number of catch-all roles to absorb whatever scraps still wouldn't cluster into anything more specific.

The result: roughly 70 roles total, a shared core for every job family and a small set of add-ons on top, with the individual one-off layer eliminated entirely. Every single user is covered by a named, reusable role, not a personal one.

The price: roughly $624,000 a year, about 11% above the strict design's $564,000, with a modest number of users, well under 5% of the population, carrying slightly more access than their individual evidence alone would justify. That's the number the client asked to see, and the number they accepted, with full visibility into exactly what it bought them.

Shipping it in pieces, not all at once

The client's last request was procedural rather than mathematical: don't cut the whole environment over at once, ship it one recognizable department at a time, so any surprise is contained and correctable before the next group goes live. That's a request we build for by default now, and it meant carving self-contained delivery batches, security objects, the user-role assignment file, a plain-English role catalogue, and a short delivery note, out of the already-finished design, rather than re-running any part of the analysis per batch.

The first batch went live at the start of this month: a five-role family covering front-line customer-facing and order-support functions, replaced by a slightly larger set of purpose-built roles. The headline finding we handed the client alongside it was the kind of number that makes a redesign easy to justify on its own: the five legacy roles being replaced were, by the telemetry and audit evidence, only 15 to 32% utilized. Most of what each one granted had never been the reason anyone was assigned it, it was simply included, unused, because it happened to sit inside a role built around a job title rather than a set of tasks.

Roughly 180 users moved onto the new roles in that first batch. The remaining departments are still on the legacy model, rolling out on the same batch-by-batch schedule, each one re-validated against current telemetry before it goes live rather than assumed still correct from the original analysis.

What we'd tell the next client choosing between these two numbers

• Ask which question you're actually answering. "Cheapest defensible design" and "design our team can operate" are both legitimate goals, and they rarely produce the same role count. Decide which one you're optimizing for before you see either number, not after.
• A consolidation premium is a real, quotable number, not a vague trade-off. Being able to say "roughly 11% more, for a tenth of the roles" turns an abstract manageability concern into something a finance team can actually approve.
• Batch the rollout even when the design is finished. A completed role model doesn't have to move all at once, and re-validating each batch against current telemetry before cutover catches drift the original analysis couldn't have seen.

Questions we get asked