At a glance
- Organization
- Professional-services enterprise, $1.3B revenue, approximately 4,800 professionals.
- Situation
- A $62M authorized modernization across CRM, CPQ, professional-services automation, and finance and data integration — 31 workstreams, $38M of claimed annual benefit.
- Complication
- The technology plan was sound. The future operating model — decision rights, handoffs, authoritative data, and the behavior required at go-live — had not been specified.
- Entry point
- Zero-Based Scoping™ leading into Zero-Based Transformation™. SORT and DO were the most visible stages.
- Result
- $9M of investment avoided before build; benefit case reset from $38M to $24M underwritten; $21M of modeled annualized benefit — 87.5% of the underwritten case, on a $53M remaining investment base.
The program was well built
This was not a troubled implementation. The architecture had been reviewed, vendors were selected, the roadmap sequenced dependencies sensibly, and the business case had been through finance. Scope spanned the commercial and delivery spine of the business: CRM, CPQ, professional-services automation, and the finance and data integration between them.
The program had also been resourced properly. Workstreams had leads, milestones had dates, and reporting was in place before the first configuration decision. Judged as a technology delivery, it was in better shape than most.
That is what made the gap difficult to see. Everything a steering committee normally inspects was present and healthy. What was absent was not a delivery artefact at all.
A benefit case resting on unanswered questions
The $38M of claimed annual benefit depended on the business operating differently after go-live. Nowhere in the program material was that difference specified. The questions the benefit actually rested on were all still open:
- Who owns decisions that cross sales, pricing, staffing, delivery and finance? The platforms would route work between those functions; nobody had decided who decides.
- What changes in the work itself? Beyond the interface people would use, what would a pricing analyst or an engagement manager actually do differently.
- Which existing handoffs disappear? A material share of the benefit assumed handoffs would be removed rather than digitized.
- Which data becomes authoritative? Several functions maintained their own version of the same commercial record.
- Which roles gain or lose decision rights? Including the roles whose discretion the new model would necessarily reduce.
- What operating behavior has to exist at go-live? Because if it does not exist on day one, the benefit does not begin accruing on day one either.
Will the platform actually change how the business operates?
An implementation can answer none of those questions and still deliver exactly what was specified. That is the risk this case turns on: technology delivery and operating change are separate achievements, and only one of them was funded with a plan behind it.
Why “go-live” is not the test
The conventional assurance for a program of this kind is delivery assurance: is the build on schedule, is testing progressing, is the organization ready to adopt. Each is necessary. None of them tests whether the operating model will convert the technology into performance.
Change management has the same boundary. It can establish that people have been trained, that communications landed, and that adoption metrics are healthy. Adoption proves compliance with a new interface. It does not prove that decision rights moved, that a handoff was removed, or that the enterprise now runs differently.
The consequence is a well-documented pattern: the implementation goes live as specified, the adoption dashboard is green, and the business case quietly fails to arrive. Two events that should be the same event turn out never to meet.
Requirements stated before delivery counts as evidence
Zero-Based Transformation treats the operating model as the subject and the platform as an instrument. The work was to state what the model had to be able to do, then test each workstream against it — before configuration decisions became expensive to revisit.
First, the operating-model requirements
The transformation objective was translated into explicit requirements across seven domains: process, roles, systems, data, governance, decision rights, and performance evidence. Stating them in those terms matters, because a requirement expressed as a system capability can be satisfied by configuration while the operating question behind it stays open.
Second, the workstream test
Each of the 31 workstreams was examined for an explicit connection between the technology it would deliver and the operating outcome expected of it. Not a mapping to a strategic theme — a stated change in how work would move, and the benefit that change would produce.
Eleven workstreams could not carry that connection. In most cases the technology was genuinely useful; what was missing was any account of the operating change that would convert it into the benefit claimed.
Third, the reset
Rather than leave those workstreams to be justified retrospectively, they were dispositioned before build. Some were retired, some consolidated where two were pursuing one operating change, and some rescoped against a requirement that had now been stated. The benefit case was reset to what could be underwritten on that basis.
What survived the operating-model test
| Line | Value | Basis |
|---|---|---|
| Initial workstreams | 31 | As authorized |
| Without a sufficiently explicit operating link | 11 | Technology delivered, outcome unexplained |
| Retired or consolidated | 7 | Removed before build |
| Materially rescoped | 4 | Retained against a stated requirement |
| Proceeding substantially intact | 20 | |
| Investment avoided through retired scope | $9M | Capital not spent — separate from the benefit reset |
| Benefit case: claimed → underwritten | $38M → $24M | Underwritten: what survived evidence testing |
| Modeled annualized benefit | $21M | 87.5% of the underwritten case |
| Remaining investment base | $53M | $62M authorized less $9M avoided |
| Indicative payback on remaining investment | ~2.5 yrs | $53M against $21M annualized — modeled indication, not a cash schedule |
The $14M difference between the claimed and underwritten case was not lost value. It was value that could not survive underwriting at the level originally claimed.
What was decided
Seven workstreams were retired or consolidated and four materially rescoped, removing $9M of scope before any of it was built. Twenty proceeded substantially intact — now against stated operating requirements rather than delivery milestones alone.
The benefit case was restated at $24M and governed at that level. This was the harder decision of the two: a sponsor who has secured $62M against a $38M return does not enjoy revising the return downward. The alternative was to defend $38M later with no evidence path behind $14M of it.
Decision rights were assigned before configuration, not after. Where the new model reduced a role’s discretion, that was made explicit and owned by a named executive rather than discovered by the role at go-live.
The results
After implementation and stabilization, the model produces $21M of annualized benefit against the $24M underwritten case — 87.5% of the underwritten value. Against the original $38M claim the same $21M reads as 55%, which is the difference between reporting against a number that was tested and one that was asserted. Finance validation is the recognition standard each line is held to, not a historical event this case reports.
$21M of modeled annualized benefit against a $24M underwritten case — 87.5% of the underwritten value. Finance validation is the recognition standard, not a historical event reported by this modeled case.
The $9M of avoided investment is the cleaner outcome, because it was never spent. Scope removed before build releases capital, capacity and calendar simultaneously; the same scope removed after build releases none of them.
On the remaining investment base — $62M authorized less the $9M avoided, or $53M — $21M of modeled annualized benefit gives an indicative payback of approximately two and a half years. That is a modeled indication on annualized benefit, not a cash-flow schedule.
The $9M of investment avoided and the $14M of benefit removed are separate adjustments and are not causally linked. Scope was retired because it could not evidence an operating outcome; the benefit case was reset because $14M of claimed benefit could not be underwritten at the level claimed. Some retired scope carried none of the removed benefit, and some removed benefit sat behind scope that continued.
Why the result held
The benefit was underwritten against operating change rather than deployment, so go-live was a step toward the result instead of a substitute for it. When the benefit is put to Finance validation the evidence exists, because the requirement specified in advance what that evidence would look like.
Technology delivery was converted into an operating-model transformation rather than being treated as the transformation itself. That is the whole of the difference between this program and the pattern the research describes.
What this means if you are about to configure
A sound architecture is not an operating answer. If nobody can state what changes in the work, the benefit case is resting on an assumption rather than a design.
Test each workstream for its operating outcome. A workstream that cannot name the change it produces will not produce the benefit attributed to it.
Configuration is the wrong place to discover decision rights. Once encoded, they are expensive to move — and the platform will enforce whatever was assumed.
If a blueprint is about to freeze and the operating model has not been specified, the platform will faithfully encode whatever model it finds. That is the cheapest moment to check, and the last one at which checking is cheap.
Evidence basis
The gap between deployment and performance is the documented pattern in this category, and the research points beyond the technology itself.
- McKinsey, Rewired for value: digital and AI transformations that work. Large companies globally captured, on average, 31% of expected revenue lift and 25% of expected cost savings from digital and AI transformations — and the analysis points beyond technology to strategy, operating model, talent, data, scale and adoption. Cited as context. See also Losing from day one (n=1,034) on where transformation value is lost.
- Thomson Reuters Institute, 2025 C-Suite Survey (200 C-Suite executives across eight countries, fielded April 2025). Digital transformation was ranked a high priority by 82% of respondents, while only 3% said their organizations had achieved a fully integrated, agile digital ecosystem.
ETEGY · ZBT in Practice · Case 02 · Technology & operating model · etegy.com