Cost-Benefit Analysis Framework for Case Interviews

The cost benefit analysis framework is useful when a case asks whether a client should proceed with a choice: invest, launch, automate, outsource, expand, pilot, delay, or stop. It is not a magic framework label. It is a business decision method that compares the expected value of an action with the resources, disruption, risks, and tradeoffs needed to pursue it. In an interview, your job is to turn that logic into a clear case structure: define the client objective, compare realistic alternatives, separate cost and benefit branches, pressure-test timing and risk, then recommend against a decision rule. Use it when the prompt already sounds like a go/no-go decision. Avoid it when the interviewer still expects diagnosis, such as why profit is falling or why customers are leaving. The stronger answer is not benefits minus costs. It is a decision the client can act on.

Related guide: case structure vs case framework explains why a framework is a starting point, not a script.

What the cost-benefit analysis framework actually answers

The cost-benefit analysis framework answers a decision question: should the client spend scarce resources on this option, choose a different option, pilot the idea, or walk away? HBS Online frames cost-benefit analysis as comparing projected costs and benefits before making a business decision. That is the right simple definition, but consulting cases require more judgment than a spreadsheet label.

A candidate-ready version starts with the objective and the alternatives. What is the client optimizing for: profit, cash, service quality, strategic position, risk reduction, or speed? What realistic options are on the table? From there, build the comparison. Direct costs are only part of it. You also need disruption, opportunity cost, measurable upside, intangible impact, timing, and implementation risk. Serious appraisal guidance such as HM Treasury's Green Book treats appraisal as a comparison across options, costs, benefits, and risks, which is a useful guardrail for cases.

The case answer is never: I used cost-benefit analysis. The answer is: proceed, reject, pilot, delay, or change the option.

When to use it in a case interview

Use it when the prompt is already a choice. Good fits include investment decisions, automation, technology adoption, outsourcing, capacity expansion, market entry economics, pricing changes with implementation cost, and project prioritization. It also works when the interviewer asks the client to choose between option A and option B, as long as the objective is clear.

Avoid it when the case is still diagnostic. If the prompt says profit has declined, start with a profitability case interview guide style tree before evaluating fixes. If the prompt asks whether a market is attractive, use market entry case interview guide logic before pricing the actual entry move. That distinction matters because McKinsey describes case interviews as business scenarios that test analytical thinking and problem solving, not memorized templates. Bain also frames interviews around how candidates think through problems. A framework helps only when it matches the job the case is asking you to do.

Use it when: the client already has an action to evaluate. Avoid it when: the client still needs to know what is happening.

Cost-benefit table: the branches to build

Build the tree around comparison, not around accounting labels. A MECE framework helps you keep costs, benefits, risks, and timing from leaking into each other. A driver tree helps turn vague labels like customer experience or labor savings into measurable drivers when the interviewer gives data.

If you want to test whether this structure works under interview pressure, Road to Offer helps by forcing the branches, data requests, and priority path into a spoken issue tree before you enter a full case.

Worked example: should a retailer automate checkout?

Prompt: A retailer is considering automated checkout across stores. Candidate opening: I would test whether automation creates enough net benefit versus realistic alternatives, while protecting customer experience and store reliability.

The starting questions are practical. What is the objective: lower operating cost, shorter queues, better staffing flexibility, or improved customer experience? Which stores are in scope? What is the alternative: better scheduling, redesigned queues, or a smaller pilot? What time horizon does management care about? What risk would make the project unacceptable even if the base economics look positive?

The cost side includes technology, installation, training, maintenance, downtime, theft or fraud controls, and manager attention. The benefit side includes lower labor need, higher throughput, better data, smoother peak periods, and customer experience improvement. Risks include reliability, adoption, shrink, employee impact, and failure during busy periods.

Candidate synthesis: I would recommend a pilot if the measurable labor and throughput benefits cover implementation and disruption costs under conservative assumptions, and if customer experience risks can be controlled. I would delay or reject the rollout if savings depend on unrealistic adoption or create service failures. Road to Offer's Case structure builder can help turn these branches into a verbal issue tree before timed practice.

Questions to ask before choosing a branch

Use branch-selection questions before you rush into math.

Objective: What decision does the client need from me? What metric defines a good outcome? Is the objective financial, operational, strategic, or risk-based?

Alternatives: What realistic options are being compared? Is doing nothing a valid baseline? Is the client choosing a full rollout, pilot, delay, or rejection?

Economics: Which cost bucket could kill the case? Which benefit is measurable enough to quantify? What driver changes the answer: volume, margin, labor, time saved, churn, reliability, or capacity?

Execution: What has to change operationally for the option to work? Who bears the disruption? Which constraints could slow implementation?

Risk: What risk is hard to quantify but material? What assumption would reverse the recommendation? What evidence would make a pilot better than a full rollout?

Mistakes that make cost-benefit analysis weak

Mistake: forcing it onto diagnostic cases. Correction: diagnose the problem before evaluating solutions. Profit decline, churn, and operations breakdowns usually need root-cause structure before cost-benefit logic.

Mistake: double-counting benefits. Correction: separate drivers cleanly. If shorter queues increase conversion and also improve satisfaction, explain how each effect will be measured so the same value is not reused. This is where MECE thinking matters.

Mistake: ignoring opportunity cost. Correction: compare the initiative with realistic alternatives, including doing nothing, piloting later, or investing in a competing project. Cost-benefit analysis is weaker when the alternative is hidden.

Mistake: treating intangible benefits as impossible to discuss. Correction: name them, then decide whether they affect the recommendation. Brand trust, service quality, strategic flexibility, and employee impact can matter even when they are not easy to price.

Mistake: hiding behind finance vocabulary. Correction: use plain business language unless the interviewer asks for a finance lens. The goal is a decision, not a glossary.

Mistake: doing math before defining the decision rule. Correction: say what would make the option attractive before calculating. That keeps the math tied to the client question.

Mistake: ending with benefits outweigh costs. Correction: synthesize. Recommend proceed, reject, pilot, or delay, then give the main reason, the key risk, and the next test.

Practice drill: turn the framework into a recommendation

Road to Offer practice should move from structure to quant to synthesis. Start with Case interview structure drill: take a decision prompt and build the objective, alternatives, cost buckets, benefit buckets, risks, timing, and decision threshold out loud. Then use Case interview math practice for cost savings, revenue uplift, margin impact, and sensitivity. If the case gives a chart, use the Chart and exhibit drill to separate useful evidence from noise.

When the decision depends on the volume, savings, or margin needed to justify fixed investment, sanity-check the setup with the Breakeven calculator. Then finish with the Synthesis drill: recommendation, reason, risk, next test.

For a full-case follow-up, choose the EV Charging Hub Profitability case inside free case practice. It is a good fit because investment economics and profitability reasoning force you to decide whether cost-benefit logic is the right tool or only a later layer after diagnosis.

When you can build the branches and defend the recommendation, move to a full case so the same logic has to survive ambiguity, math, and synthesis.

Sources and Further Reading (checked 2026-06-01)

• Harvard Business School Online - What Is Cost-Benefit Analysis and How to Do It
• HM Treasury - The Green Book
• The White House Office of Management and Budget - Circulars
• McKinsey & Company - Interviewing at McKinsey
• Bain & Company - Our Hiring Process
• Yale Office of Career Strategy - Consulting