SD-WAN Value Story Fails Finance Scrutiny
A global manufacturer has run Cisco SD-WAN at 250 branch sites for 14 months. The approved business case promised a 30% reduction in network cost over three years and 99.95% WAN availability. Finance has now calculated only 8% savings because MPLS contracts overlap for 18 months and two carriers were kept for redundancy. Availability is 99.91%, missing the target but not causing reported outages. Application latency improved for SAP, but the team never baselined SAP transaction time, so the benefit is anecdotal. The CFO is questioning the program and wants the QBR to show 'the real number'. The network director is defensive and points to faster circuit provisioning and fewer change windows. The account team wants to avoid discussing the savings gap.
1. How would you structure a value realization review that is credible to the CFO without undermining the network director?
Read the worked answer
I would structure the review around four value categories, each with evidence status: verified, projected, unvalidated, and at risk. That prevents a single blended number from becoming a political fight.
First, verified cost: the 8% savings finance calculated. I would show the calculation, the contract overlap, and the timing. Second, projected cost: savings that arrive when MPLS contracts expire, with dates and owners. Third, operational value: faster circuit provisioning, fewer change windows, and availability. I would quantify these where possible, for example change tickets avoided and average provisioning days reduced. Fourth, unvalidated value: SAP latency. I would label it as unvalidated and propose a baseline now.
The review should explicitly recognize the network director's operational wins before discussing the gap. That is not softening the message; it separates design success from benefits realization. The CFO needs to see that the program is not failing everywhere, but the original business case used a three-year curve that has not been managed. I would end with a revised benefits forecast and the decisions needed, not a defensive narrative.
2. What should you do about the 8% versus 30% savings gap and the missing latency baseline?
Read the worked answer
I would classify the gap into timing, scope, and measurement. Timing: MPLS overlap for 18 months and retained dual carriers explain part of the difference. Scope: the original case may have assumed carrier rationalization that was never approved. Measurement: finance may be counting only circuit spend, while the business case may have included operational savings.
Then I would rebuild the forecast rather than defend the original number. I would produce a bridge from 8% to the realistic three-year figure, with each item owned and dated. For the missing latency baseline, I would not claim retroactive benefit. I would establish a baseline now for SAP transaction time at a representative set of sites, then measure over 60 to 90 days. In the meantime, I would use proxy evidence: change-window counts, provisioning lead time, and incident duration.
I would also ask the CFO to agree on the measurement method for the next review. That protects both sides from another disputed number. The network director should own the operational proxies; finance should own the cost calculation. The CSM owns the bridge and the review cadence.
3. Define three business outcomes with measures that could be used in the next QBR.
Read the worked answer
Outcome 1: Reduce network cost per site without reducing resilience. Measure: verified circuit and carrier cost per site, MPLS contract exit dates, and savings bridge versus the original case. Include a resilience check so cost is not achieved by removing required redundancy.
Outcome 2: Improve network change velocity for branch openings and changes. Measure: average circuit provisioning lead time, number of change windows per quarter, and percentage of changes completed without incident. This validates the network director's operational claim without overstating financial value.
Outcome 3: Improve SAP experience at priority branches. Measure: SAP transaction response time against a newly established baseline, incidents attributed to WAN latency, and user-reported friction in the top 20 branches.
For each outcome I would state the owner, data source, baseline, target, and review date. I would also label which outcomes are verified today and which are projected. That gives the CFO a real number and a path, and gives the network director recognition for operational improvements that the original business case did not measure.