Three metrics interact across one portfolio, and buyers without preparation overpaid 30 to 50 percent on the mechanics alone
Three primary metrics, dozens of SKUs, and a sub capacity rule that governs all of them conditionally. The overpayment here is not a pricing failure. It is a mechanics failure, and it is correctable with measurement rather than with negotiation.
Prepared by Redress Compliance · August 16, 2026 · IBM advisory.
Executive summary
Buyers without preparation routinely overpaid 30 to 50 percent, because the metric mechanics are poorly understood rather than because the pricing is unusually aggressive.
Three primary metrics interact: PVU, RVU, and capacity based. They apply across dozens of SKUs spanning QRadar, Guardium, MaaS360, AppScan, Resilient, and the Spectrum storage family, and they do not behave alike.
Sub capacity reclassification alone delivered 40 to 70 percent reduction on the affected PVU counts. It is the single highest leverage move on the renewal, and it is an evidence exercise rather than a negotiation.
The combined effect across Security and Storage is typically 25 to 40 percent at renewal. That is achieved before the discount conversation, by correcting how the estate is counted.
Three metrics, and how they differ
IBM Security and Storage is the most metric heavy commercial surface in enterprise software, and the metrics are not variations on a theme.
| Metric | What it counts | Sub capacity applies |
|---|---|---|
| PVU | Cores times a rating by processor family | Yes, conditional on ILMT |
| RVU | Resource units, defined per product | Varies by product definition |
| Capacity based | Managed capacity, typically storage | Governed by the capacity definition rather than by hosts |
The portfolio spans QRadar, Guardium, MaaS360, AppScan, Resilient, and the Spectrum storage family, across dozens of SKUs, and a single estate commonly carries all three metrics at once. That is what produces the 30 to 50 percent overpayment among unprepared buyers: not one badly negotiated line, but a portfolio counted inconsistently because no single person holds all three mechanics. The remedy is a metric by metric inventory rather than a better discount.
A mechanics failure, not a pricing failure
Buyers on IBM Security and Storage routinely overpay by 30 to 50 percent, and the reason is worth stating precisely because it changes what to do about it. The overpayment is not the product of aggressive pricing or weak negotiation. It comes from metric mechanics that are poorly understood and a sub capacity discipline that is rarely enforced. Those are measurement problems, and measurement problems are not solved by discount.
The structural difficulty is that three primary metrics operate simultaneously across one portfolio. PVU counts cores times a rating by processor family. RVU counts resource units defined per product, so the definition changes as you move across the catalogue. Capacity based metrics count managed capacity, typically in storage, and are governed by a capacity definition rather than by hosts. An estate running QRadar, Guardium, and Spectrum is being counted three different ways at once, and very few organisations have one person who holds all three mechanics well enough to see where the counting has drifted.
Within that, one move outperforms everything else. Sub capacity reclassification of every PVU licensed product delivered 40 to 70 percent reduction on the affected counts, which makes it the single highest leverage action on the renewal. It is also, importantly, not a negotiation. The entitlement already permits sub capacity; what is missing is the ILMT evidence that makes the permission claimable. So the work is operational and it produces a commercial result, which is an unusual and favourable combination.
Taken together, the combined effect across Security and Storage is typically 25 to 40 percent at renewal, achieved before any discount conversation opens. That ordering is the practical conclusion. Correct how the estate is counted first, metric by metric, because a discount applied to an inconsistently counted portfolio compounds the original error rather than offsetting it. The sub capacity mechanics sit in sub capacity and ILMT, the wider posture in the vendor management playbook, and the library in the IBM practice.
- Your agreements decoded into plain English before the auditor interprets them for you
- PVU, RVU, and capacity counts reconciled separately against real deployment
- A defensible position paper generated in minutes, not weeks
The order the work has to happen in
- Inventory by metric, not by product, since one estate commonly carries PVU, RVU, and capacity based counting simultaneously and the drift differs by metric.
- Run the ILMT compliance audit first, because sub capacity reclassification is the highest leverage move and it is conditional on evidence.
- Reclassify every PVU licensed product to sub capacity, which delivered 40 to 70 percent on the affected counts.
- Check the RVU definition per product, since resource units are defined per product rather than uniformly and the definition is where the count comes from.
- Test capacity based metrics against the capacity definition, not against hosts, because storage metrics are governed differently.
- Take the discount last, against a corrected count, since a discount on an inconsistently counted portfolio compounds the error.
Where the overpayment comes from
The pattern across IBM Security and Storage estates is a counting problem rather than a pricing one:
Reduction on the affected PVU counts, achieved by evidencing an entitlement the estate already holds.
Typical total reduction across Security and Storage, reached before any discount conversation opens.
Three primary metrics, PVU, RVU, and capacity based, interact with sub capacity rules that depend on ILMT compliance, across a portfolio spanning QRadar, Guardium, MaaS360, AppScan, Resilient, and the Spectrum storage family.
The single highest leverage move on every renewal is the ILMT compliance audit followed by sub capacity reclassification of every PVU licensed product. Neither is a negotiation, and both produce commercial results.
Your first five moves
- Build a metric by metric inventory across the portfolio, since PVU, RVU, and capacity based counting all run simultaneously on most estates.
- Run the ILMT compliance audit before anything commercial, because it is the condition on the largest available reduction.
- Reclassify every PVU licensed product to sub capacity, which is worth 40 to 70 percent on the affected counts.
- Verify the RVU definition per product, rather than assuming resource units are defined consistently across the catalogue.
- Open the discount conversation last, against a corrected count. The IBM practice runs the inventory with you.
Frequently asked questions
Why do buyers overpay on IBM Security and Storage?
Because the metric mechanics are poorly understood and the sub capacity discipline is rarely enforced. Unprepared buyers routinely overpay 30 to 50 percent, and it is a measurement failure rather than a pricing or negotiation failure.
Which metrics apply?
Three primary ones: PVU counting cores times a processor family rating, RVU counting resource units defined per product, and capacity based metrics counting managed capacity, typically in storage. Most estates carry all three at once.
Why does carrying three metrics matter?
Because they do not behave alike and very few organisations have one person who holds all three mechanics. An estate running QRadar, Guardium, and Spectrum is counted three different ways simultaneously, and drift in any of them goes unnoticed.
What is the single highest leverage move?
The ILMT compliance audit followed by sub capacity reclassification of every PVU licensed product. It delivered 40 to 70 percent reduction on the affected counts and it is an evidence exercise rather than a negotiation.
How much can a renewal move overall?
Typically 25 to 40 percent across Security and Storage combined, and that is reached before the discount conversation opens, purely by correcting how the estate is counted.
Is sub capacity a discount we negotiate?
No. The entitlement already permits it. What is usually missing is the ILMT evidence that makes the permission claimable, which is why the work is operational and the result is commercial.
What does RVU actually count?
Resource units, defined per product rather than uniformly across the catalogue. That means the definition changes as you move between products, and reading the definition is where the count comes from.
How do capacity based metrics differ?
They count managed capacity and are governed by the capacity definition rather than by hosts, which makes host level reasoning misleading when applied to storage products.
Which products are covered?
Dozens of SKUs across QRadar, Guardium, MaaS360, AppScan, and Resilient on the security side, and the Spectrum family on the storage side. The breadth is part of why the counting drifts.
Should the discount come first or last?
Last, always. A discount applied to an inconsistently counted portfolio compounds the original error rather than offsetting it, because the percentage attaches to a quantity that was wrong before the conversation started.
