A stakeholder arrives with a supplier proposal and asks procurement to “get the best price”. The demo has happened, the preferred option is already named and the project is described as urgent. Nobody has written down the current cost, the operational problem, the alternatives or who will own implementation.

At that point, negotiation is not the first procurement problem. The missing business case is.

A useful business case makes a decision inspectable. It explains the problem, baseline, options, value, cost, risk, delivery requirements and ownership without disguising assumptions as facts.

TL;DR

  • Start with the problem and current baseline, not the preferred supplier.

  • Compare credible options, including doing nothing or improving the current process.

  • Separate cashable savings, cost avoidance, capacity, risk reduction and strategic value.

  • Show assumptions, evidence, ranges and sensitivity instead of manufacturing a precise ROI.

  • Include implementation cost, operating change, dependencies, risks and benefit ownership.

  • Write for the decision that must be made: approve, reject, test, defer or request more evidence.

What a procurement business case is

A procurement business case is a structured argument for a proposed purchase, sourcing project or change. It should help an accountable decision-maker answer:

  • What problem are we solving?

  • Why now?

  • What happens if we do nothing?

  • Which options were considered?

  • What value, cost and risk does each option create?

  • Can the organisation implement and adopt it?

  • Who owns the outcome?

It is not a longer purchase request and it is not a vendor proposal with internal branding.

When a business case is needed

Use a proportionate business case when the decision creates material cost, risk, change, dependency or opportunity. The required depth should reflect consequence, not simply follow one financial threshold.

A short case may be enough for a low-risk renewal with clear performance and market evidence. A new core platform, outsourced service or operational dependency needs deeper options, assurance, implementation and exit analysis.

The eight-part business-case framework

1. Decision and recommendation

State the decision required in one sentence. Then state the recommendation, approval limit, timing and conditions.

Example structure: Approve a controlled pilot, subject to security review, agreed success measures and a named implementation owner.

2. Problem and desired outcome

Describe the current problem in operational language. Who experiences it? What work, risk, delay, cost or constraint does it create? What would be observably better?

Avoid “we need a new system” as the problem statement. The need may be faster intake, reliable supplier data, fewer manual handoffs or better contract visibility. A system is one possible response.

3. Current baseline

Capture the evidence available today:

  • current spend and contractual commitments;

  • volumes, cycle times or workload;

  • error, exception or rework patterns;

  • risk events and control gaps;

  • systems and manual work involved;

  • stakeholders and affected users.

Record source, period, owner and limitations. If the baseline is incomplete, say so and explain how that uncertainty affects the decision.

4. Options

Compare a real set of alternatives:

  • do nothing;

  • improve the existing process or configuration;

  • build internally;

  • buy a product or managed service;

  • run a time-limited pilot;

  • change scope or sequence.

A business case with one vendor and no alternative is usually a purchase justification, not an options analysis.

5. Value and benefits

Separate value types so unlike claims are not added together without thought:

  • Cashable savings: budget that can genuinely be removed or avoided.

  • Cost avoidance: future expenditure that may not occur.

  • Capacity: time released, with a clear explanation of how it will be used.

  • Revenue or service impact: value to customers or operations.

  • Risk reduction: change in exposure, controls or recovery capability.

  • Strategic value: capability, data, speed or flexibility that supports a defined priority.

Name a benefit owner and measurement method for each material claim. Procurement may help build the case; it should not be left owning operational benefits it cannot deliver.

6. Total cost

Include more than subscription or unit price:

  • implementation and integration;

  • internal project time;

  • data preparation and migration;

  • training and change;

  • support and administration;

  • usage growth and price escalation;

  • renewal, switching and exit costs;

  • parallel running or transition.

Use the Total Cost of Ownership framework for a fuller model.

7. Risk, dependencies and controls

Show what could prevent the outcome:

  • poor source data;

  • unclear ownership;

  • integration or security dependencies;

  • supplier concentration or lock-in;

  • low user adoption;

  • policy, legal or regulatory constraints;

  • unproven product capability;

  • implementation capacity.

For each material risk, state the owner, mitigation and decision consequence. A business case should expose uncertainty, not hide it.

8. Delivery and measurement

Set out:

  • delivery phases and decision gates;

  • named business, procurement and technical owners;

  • success measures and baseline;

  • review dates;

  • conditions for scaling, changing course or stopping;

  • how benefits will be tracked after contract signature.

For technology purchases, complete the implementation-readiness checklist before treating the commercial case as complete.

A reusable one-page template

Copy this structure into your working document:

  • Decision required: [approve / reject / pilot / defer / request evidence]

  • Problem: [who experiences what problem, and why it matters]

  • Baseline: [current cost, volume, time, risk or service evidence, with sources]

  • Desired outcome: [observable change and target period]

  • Options: [do nothing, improve, build, buy, pilot or alternative scope]

  • Recommendation: [option and rationale]

  • Benefits: [type, amount or range, evidence, owner and timing]

  • Total cost: [one-off, recurring, internal, transition and exit]

  • Risks and dependencies: [risk, owner, mitigation and decision impact]

  • Delivery: [phases, accountable owner and key dates]

  • Measurement: [baseline, success measures and review cadence]

  • Conditions: [approvals, assurance and stop/go criteria]

How to handle ROI without inventing certainty

Use ranges when inputs are uncertain. Show the formula and source for each material input. Separate vendor claims from internal evidence and World of Procurement judgement.

Test sensitivity: what happens if adoption is slower, volume is lower, implementation costs rise or only part of the expected capacity is redeployed?

For AI investments, the Procurement AI ROI framework shows how to build a credible case without turning theoretical time savings into guaranteed cash.

Evaluating suppliers inside the business case

Do not let the business case become a disguised comparison of marketing claims. Define the use case, evidence standard, buyer segment and validation questions before deciding which suppliers belong in the evaluation.

Use the procurement software evaluation framework for the buyer process and the Procurement AI Technology Landscape for a broader market view where AI technology is in scope.

Common business-case failure modes

  • the supplier is selected before the problem is defined;

  • doing nothing is excluded from the options;

  • capacity is presented as cashable savings;

  • only licence price is counted;

  • implementation is assumed to be somebody else’s problem;

  • risk reduction has no baseline or control mechanism;

  • benefits have no owner;

  • precision is used to disguise weak evidence;

  • the case is approved and never reviewed again.

Frequently asked questions

Who should own the procurement business case?

The accountable business sponsor should own the outcome. Procurement can challenge the market, commercial model, evidence and supplier assumptions; finance, risk, technology and other specialists should own their relevant inputs.

How long should a business case be?

Long enough to support the consequence of the decision. Start with one page and attach detailed evidence where needed. Length is not a proxy for rigour.

Should a business case name a preferred supplier?

It can, once the problem, options and evaluation support that recommendation. If the supplier was chosen first, make that constraint explicit and test whether the case still holds.

What if the data is incomplete?

State the gap, use a transparent range, explain the decision risk and decide whether a pilot or further discovery is the appropriate next step.

Continue exploring

A good business case does not make uncertainty disappear. It makes the uncertainty visible enough for someone to take responsibility for the decision.