Value Engineering
Ross Sylvester, Co-Founder & CEO, Adrata | Mar 2026 | ~16 min read
Bill McDermott started working at age eleven. Not the sanitized kind of childhood employment that shows up in executive bios -- the real kind. He ran a delicatessen on Long Island, waking before dawn to stock shelves, learning how to read what customers actually wanted by watching what they reached for. By sixteen, he had saved enough to buy the deli outright. He did not sell sandwiches. He solved the problem of a neighborhood that needed a gathering place, a reliable lunch, a person who remembered their name. He engineered value before he had the vocabulary for it.
That instinct -- the refusal to sell a product when you could instead solve a problem -- carried McDermott through Xerox, through Siebel Systems, and eventually to the CEO chair at SAP, where he led the company from $16.8 billion in revenue in 2010 to over $35 billion by 2023.^1^ He then moved to ServiceNow, where revenue crossed $10 billion in 2024, growing at 22% year-over-year in a market where most enterprise software companies would kill for half that rate.^2^
His memoir Winner's Dream (2014) is not a sales book. It is a book about value engineering disguised as an autobiography. And the distinction matters because value engineering is not a sales technique. It is a discipline -- a systematic method of quantifying business impact, building financial models, and constructing business cases so compelling that the buyer's decision becomes self-evident.
The best sellers in the world do not pitch features. They engineer value. And the gap between those two activities is the gap between a rep who hits quota and a rep who becomes indispensable to the C-suite.
What McDermott Actually Did
Most summaries of McDermott's career focus on charisma. He is charismatic. That is the least interesting thing about him.
What made McDermott different -- at Xerox, at SAP, at ServiceNow -- was the rigor beneath the warmth. He did not walk into enterprise accounts and inspire people into buying. He walked in with a quantified understanding of their business that was often better than their own.
At Xerox in the early 1990s, McDermott was selling copiers into the most competitive market in office technology. The median rep sold on price, speed, and service contracts. McDermott calculated the total cost of document workflow for each account -- not just the hardware, but the labor cost of document handling, the error rate from manual processes, the time executives spent waiting for information that was trapped in paper. He translated a copier sale into a productivity transformation with a measurable dollar value.^3^
The copier cost $15,000. The productivity gain was worth $200,000 a year. The conversation shifted from "Can we get a 10% discount?" to "How fast can we deploy?"
At SAP, the same instinct scaled to billion-dollar deals. McDermott did not sell ERP software. He sold operational transformation. Every major account engagement started with what SAP called a Value Engineering assessment -- a structured analysis of the customer's current-state costs, the quantified impact of process improvements, and a financial model showing ROI over three to five years.^4^ By the time the proposal reached the CFO's desk, the business case had already been built -- with the customer's own numbers.
This is the critical point. McDermott did not impose value claims. He co-created them with the buyer. The customer's finance team contributed the inputs. The customer's operations team validated the assumptions. By the time the deal was ready for signature, the customer had already convinced themselves. McDermott's team simply held the mirror.
Value Engineering as a Discipline
Value engineering is not a pitch framework. It is not MEDDPICC. It is not Challenger. Those are sales methodologies -- they tell the rep how to run a deal. Value engineering is an analytical discipline -- it tells the rep what the deal is actually worth to the buyer in financial terms.
The distinction matters because methodology without economics is storytelling. You can identify the economic buyer, map the decision criteria, and run a flawless mutual action plan. But if you cannot answer the question "What is this worth in dollars, and how do we know?" -- the deal stalls at the CFO.
Gartner's 2024 research found that 77% of B2B buyers rated their last purchase as "extremely complex or difficult."^5^ Forrester found that 60% of buying committees fail to reach internal consensus, resulting in no decision.^6^ The most common reason is not competitive loss. It is the inability to build a financial case strong enough to overcome organizational inertia and competing budget priorities.
Value engineering solves this. Here is how it works.
The Four Components
Every value engineering engagement has four components. Skip any one of them and the business case collapses.
1. Current-State Quantification
Before you can demonstrate value, you must quantify the cost of the status quo. Not in abstract terms -- in dollars. Specific, auditable, defensible dollars.
This means answering questions the buyer may never have asked:
- What is the fully loaded cost of the process this product replaces? Include labor (hours x blended rate), technology costs, error/rework rates, opportunity costs of delayed decisions, and compliance risk exposure.
- What is the cost of inaction? If the buyer does nothing for 12 months, what is the quantified impact? Revenue leakage, competitive erosion, regulatory exposure, talent attrition from manual drudgery.
- What are the hidden costs? The ones that do not show up in any budget line. Shadow IT. Workarounds. The senior analyst who spends 15 hours a week building reports that should be automated. The VP who cannot get answers to basic questions without a two-week turnaround from the BI team.
McDermott's Xerox insight was exactly this. Nobody had quantified the cost of document workflow. The copier was a line item. The workflow problem was invisible -- until someone made it visible with numbers.
A practical framework for current-state quantification:
| Cost Category | Inputs Needed | Calculation |
|---|---|---|
| Direct labor | FTE count, blended rate, hours/week on process | FTEs x rate x hours x 52 |
| Technology | Current tool costs, maintenance, integration | Annual license + support + custom dev |
| Error/rework | Error rate, cost per error, rework hours | Errors/year x avg. cost per error |
| Opportunity cost | Revenue delayed, deals lost to slow process | Pipeline affected x conversion impact |
| Risk exposure | Compliance fines, audit costs, breach probability | Expected value of risk events |
The total is the Cost of Current State (CCS). This is the number the business case is built against.
2. Future-State Modeling
With the current-state cost established, model what the world looks like after implementation. This is not a feature list. It is a financial projection.
The future-state model must be:
- Conservative. Use the buyer's own benchmarks, not your marketing claims. If your case studies show 40% improvement, model 25%. The CFO will respect conservatism. They will dismiss optimism.
- Time-phased. Value does not arrive on day one. Model the ramp: Month 1-3 (implementation and training), Month 4-6 (initial adoption and early gains), Month 7-12 (full run-rate value), Year 2+ (compounding improvements and expansion).
- Segmented by stakeholder. The CFO cares about cost reduction and margin improvement. The COO cares about operational efficiency and error reduction. The CRO cares about revenue acceleration and win rates. Build separate value narratives for each.
The future-state equation:
Net Value = (Cost Reduction + Revenue Gain + Risk Mitigation) - (Implementation Cost + Ongoing Cost + Change Management Cost)
Each term must be quantified. "Better visibility" is not a term. "$1.4M in recovered pipeline from 15% improvement in deal inspection accuracy" is a term.
3. ROI and Payback Calculation
The CFO will ask two questions: What is the return? and When do I get my money back?
ROI = (Net Benefit over 3 years - Total Cost) / Total Cost
Payback Period = Total Cost / Monthly Net Benefit
Both calculations must use the buyer's discount rate, not yours. If the company's weighted average cost of capital is 12%, use 12%. If they have a hurdle rate of 25% for new technology investments, your ROI must clear 25%.
Here is where most value engineering efforts fail. They calculate a theoretical ROI using assumptions the CFO has never validated. The number looks impressive on a slide. The CFO asks one question about the labor savings assumption, the seller cannot answer, and the entire model loses credibility.
McDermott's discipline was to co-build the model with the buyer's finance team. Not present it to them. Build it with them. When the CFO's own analyst has validated the assumptions, the ROI is not your claim. It is their conclusion.
Example ROI model structure:
| Category | Year 1 | Year 2 | Year 3 | 3-Year Total |
|---|---|---|---|---|
| Cost savings | $480K | $720K | $720K | $1,920K |
| Revenue uplift | $200K | $800K | $1,200K | $2,200K |
| Risk reduction | $150K | $150K | $150K | $450K |
| Gross benefit | $830K | $1,670K | $2,070K | $4,570K |
| Implementation | ($350K) | -- | -- | ($350K) |
| Annual license | ($180K) | ($180K) | ($180K) | ($540K) |
| Change management | ($100K) | ($50K) | -- | ($150K) |
| Net benefit | $200K | $1,440K | $1,890K | $3,530K |
ROI = $3,530K / $1,040K = 339%
Payback = $1,040K / ($3,530K / 36) = 10.6 months
4. Total Cost of Ownership
TCO is the counterweight to ROI. The buyer needs to know not just what they gain, but what they spend -- fully loaded, with no surprises.
TCO includes:
- Direct costs: License, subscription, or usage fees. Implementation services. Data migration. Integration development.
- Indirect costs: Internal project management time. Training and enablement. Change management. Temporary productivity dip during transition.
- Ongoing costs: Support and maintenance. Upgrades. Additional modules. Internal administration.
- Hidden costs: Customization that creates upgrade friction. Vendor lock-in switching costs. Technical debt from integration complexity.
The best value engineers present TCO proactively. They do not wait for the buyer to ask. They build a comprehensive TCO model, compare it to the TCO of the status quo (which is almost always higher than anyone realizes), and frame the decision as a TCO reduction with value creation on top.
This is what McDermott meant when he wrote in Winner's Dream: "Dream big, but be practical." The dream is the transformation. The practicality is the financial model that makes the dream fundable.
Why Value Engineering Wins at the C-Suite
Enterprise deals die in the middle of the org chart. They are born in meetings with champions who love the product. They are killed by committees who cannot justify the spend.
Value engineering is the bridge between enthusiasm and authorization. Here is why it works at the C-suite level when feature pitches do not.
CFOs think in terms of capital allocation, not capabilities. When a rep says "Our platform improves forecasting accuracy by 30%," the CFO hears a claim. When a rep says "Based on your current forecast miss rate of $4.2M per quarter and your blended cost of capital of 11%, improving forecast accuracy by 30% -- which is the conservative end of what customers in your vertical have achieved -- represents $5.04M in recovered annual revenue and $554K in reduced capital reserve requirements," the CFO hears a capital allocation decision with quantified upside.
CEOs think in terms of strategic outcomes, not operational improvements. McDermott understood this at SAP. He did not sell the CEO on better ERP. He sold them on business model transformation -- the ability to move from product-centric to customer-centric operations, to enter new markets faster, to acquire and integrate companies on a unified platform. The value was strategic, and the financial model proved it was achievable.
Boards think in terms of risk-adjusted returns. A business case that shows 500% ROI but ignores implementation risk is not credible. A business case that shows 200% ROI with a detailed risk analysis, sensitivity tables, and downside scenarios is fundable. Value engineering builds the risk-adjusted model that boards actually approve.
The McDermott Playbook: Five Principles
Across Winner's Dream and McDermott's public record, five principles of value engineering emerge. They are not abstract. They are operational.
1. Lead with Empathy, Close with Math
McDermott's first move in any account was not a pitch. It was a question: What is keeping you up at night? Not the business problem. The personal problem. The CIO who is afraid of being fired if the migration fails. The CFO who needs to show the board that technology investments are producing returns. The CEO who is losing market share and does not know why.
Empathy identifies the problem that matters. Math proves you can solve it. Both are required. Empathy without math is a pleasant conversation that produces no purchase order. Math without empathy is a spreadsheet that gets forwarded to procurement for a commodity evaluation.
2. Co-Create, Do Not Present
The single most important shift in value engineering is moving from presentation to co-creation. When you present a business case, the buyer's job is to poke holes in it. When you co-create a business case, the buyer's job is to make it accurate -- which means they are building the argument for buying your product using their own data.
McDermott's SAP value engineering teams would spend weeks embedded with the customer's finance and operations teams. The output was not an SAP document. It was a joint document with the customer's logo, the customer's data, and the customer's analyst's signature on the assumptions.
Try rejecting a business case you helped build. It is almost impossible.
3. Quantify the Cost of Delay
One of McDermott's most effective tactics was calculating what inaction cost per month. If the annual value of the transformation was $4.8M, the cost of delay was $400K per month. Every month the buying committee debated was $400K in unrealized value.
This reframes the decision timeline. The question shifts from "Should we buy this?" to "Can we afford to wait?" It creates urgency without pressure -- because the urgency is mathematical, not emotional.
The delay cost formula:
Monthly Cost of Delay = Annual Net Benefit / 12
Quarterly Cost of Delay = Annual Net Benefit / 4
If your deal has been in evaluation for six months and the annual benefit is $2M, the buyer has already lost $1M by not deciding. That number belongs in the business case.
4. Build for the CFO's Red Team
Every CFO has a mental red team. They will challenge every assumption in your business case. McDermott prepared for this by stress-testing his own models before presenting them.
Build sensitivity analysis into every business case:
- What if adoption is 20% lower than projected?
- What if implementation takes 50% longer?
- What if only 60% of the identified value is realized?
If the business case still shows a positive ROI under pessimistic assumptions, it is bulletproof. If it only works under optimistic assumptions, it is not ready.
Sensitivity table example:
| Scenario | Adoption Rate | Implementation Timeline | Value Realized | ROI |
|---|---|---|---|---|
| Optimistic | 90% | On time | 100% | 450% |
| Base case | 75% | +2 months | 80% | 270% |
| Conservative | 60% | +4 months | 60% | 150% |
| Pessimistic | 50% | +6 months | 50% | 95% |
When the pessimistic case still shows 95% ROI, the CFO's red team has nothing to attack.
5. Make the Champion the Hero
McDermott wrote about this explicitly. The seller's job is not to be the hero of the deal. The seller's job is to make the internal champion the hero. The champion is the one who will present the business case to the executive committee. The champion is the one who will stake their reputation on the recommendation.
Value engineering arms the champion with everything they need to win internally:
- An executive summary they can forward to the CEO without editing
- A financial model they can defend in a budget review
- A risk analysis that preempts every objection the CFO will raise
- A competitive comparison that justifies the vendor selection
- An implementation timeline that proves the transformation is achievable
When your champion walks into the executive committee meeting with a business case this thorough, they do not look like someone who was sold to. They look like someone who did exceptional strategic analysis. That is the highest compliment a seller can receive -- and the most reliable path to a closed deal.
Value Engineering in the Age of AI
McDermott's principles were developed in an era of manual analysis. A value engineering assessment at SAP could take 6-8 weeks and require a dedicated team of consultants. This created a natural constraint: only the largest deals justified the investment.
AI changes the economics. What took a team of three analysts six weeks can now be accomplished in hours. The inputs -- financial data, operational metrics, industry benchmarks, competitive intelligence -- can be aggregated, normalized, and modeled at a pace that was impossible five years ago.
This means value engineering is no longer reserved for seven-figure deals. A rep working a $150K opportunity can build a quantified business case with the same rigor that SAP's value engineering team brought to a $50M transformation -- if they have the right tools and the right framework.
The implications for revenue organizations:
Every deal should have a value model. Not just the strategic accounts. Not just the enterprise segment. Every qualified opportunity should have a quantified business case. The cost of building one has dropped by an order of magnitude. The impact on win rates has not changed -- deals with business cases still close at 2-3x the rate of deals without them.
Value engineering becomes a rep skill, not a specialist function. In McDermott's era, value engineering was performed by a dedicated team that was brought in on strategic deals. In the AI era, every rep should be capable of building a basic value model -- because the tools make it accessible and the buyers expect it.
The competitive moat shifts from product to value articulation. When every product in a category has similar capabilities, the seller who can quantify the value of their specific solution for the buyer's specific situation wins. Not because the product is better. Because the business case is better.
The Deli Lesson
McDermott tells a story in Winner's Dream about his deli on Long Island. A customer came in every morning for coffee and a roll. One day, McDermott noticed the customer looked tired. He asked about it. The customer was working double shifts because his wife was sick and the medical bills were stacking up. McDermott started giving him breakfast for free. Not because it was good business. Because it was the right thing to do.
Months later, that customer's brother-in-law -- who ran a construction company -- started ordering catering for his entire crew from McDermott's deli. The revenue from that single referral exceeded the cost of free breakfasts by a factor of fifty.
This is the origin story of value engineering, stripped to its essence. Understand the person. Understand their problem. Solve the problem in a way that creates genuine value. The economics follow.
The best sellers in enterprise software are doing exactly what a sixteen-year-old did in a deli on Long Island. They are listening. They are quantifying. They are engineering value so obvious that the purchase decision becomes inevitable.
Bill McDermott did not invent this. He just did it better than anyone else -- with spreadsheets instead of sandwiches, and at a scale measured in billions instead of breakfast orders.
The discipline is available to anyone willing to learn it.
^1^ SAP SE Annual Reports, 2010-2023. Revenue grew from EUR 12.5B ($16.8B) to EUR 31.2B ($35.0B) under McDermott's tenure as CEO (2010-2019), with continued growth under the strategy he established.
^2^ ServiceNow Q4 FY2024 Earnings Report. Full-year revenue of $10.98B, subscription revenue growth of 22% year-over-year.
^3^ McDermott, B. Winner's Dream: A Journey from Corner Store to Corner Office. Crown Business, 2014. Chapters 3-5 detail the Xerox years and the development of his value-based selling approach.
^4^ SAP Value Engineering practice, established formally in the early 2010s. See SAP's published methodology for business case development and ROI modeling in enterprise software deployments.
^5^ Gartner, "B2B Buying Journey Report," 2024. Survey of 1,500+ B2B buyers across industries.
^6^ Forrester, "The State of Business Buying," 2024. Analysis of enterprise purchase decisions and buying committee dynamics.