How to Write a Business Case for a Hybrid Project Without Fixing Scope

## The short answer

Write the business case around **outcomes and a range of value**, not a fixed feature list. Commit firm funding only to the first stage; approve later stages *in principle*, subject to evidence. Express benefits, costs and timelines as ranges with assumptions stated, and make the business case a living document reviewed at every stage boundary. This satisfies PRINCE2's requirement for continued business justification while preserving Agile's freedom to discover the right scope as you build.

## Why fixed-scope cases fail Agile work

A traditional business case promises specific features for a specific cost by a specific date. On uncertain work, all three are guesses dressed as commitments. When reality diverges — as it must — the project is judged a failure against fictional baselines, even if it delivered more value than planned. The fix is not to abandon the business case (PRINCE2 rightly insists on justification) but to change what it commits to: **outcomes you're confident about, scope you're willing to discover.**

## Anchor on outcomes, not features

Start with the change in the world the sponsor wants. Good outcome statements are measurable and feature-agnostic:

- "Reduce the time to complete the core task" rather than "build screens X, Y and Z."

- "Increase the proportion of users who self-serve" rather than "add a chatbot."

- "Cut manual processing effort in the back office" rather than "automate workflow A."

This lets the team change *how* it achieves the outcome without rewriting the justification every sprint. Features are hypotheses about how to reach the outcome; the business case should back the outcome, not bet the budget on any single hypothesis.

## Use value ranges with stated assumptions

Replace single-point figures with ranges and name the assumptions behind them:

- **Benefit range**: a conservative, expected and optimistic estimate, each tied to a stated assumption.

- **Cost range**: driven by the funded stages, with later stages estimated more loosely.

- **Confidence**: note which numbers are evidenced and which are still assumptions to be tested.

Ranges are not vagueness — they are honesty. A board that sees an explicit range and the assumptions behind it makes better decisions than one handed a false precision it will later resent.

## Fund in stages

Structure funding to match uncertainty:

1. **Stage one — fully funded.** Enough to deliver real increments and test the riskiest assumptions.

2. **Later stages — approved in principle.** Indicative budget, released only at the boundary once evidence supports continuation.

3. **A defined stop point.** State up front what evidence would justify stopping, so stopping is a planned success of the process, not an embarrassment.

This is staged investment: spend a little to learn a lot, then decide whether to spend more.

## Make it a living document

The business case should change as you learn. At every stage boundary, update:

- **What you now know** that you didn't before, and how it shifts the value range.

- **Revised costs** based on the team's actual delivery rate.

- **Revised benefits** based on real user response to shipped increments.

- **The continuation recommendation**: proceed, adjust, pause or stop.

A business case that hasn't changed across several stages of a genuinely uncertain project is a warning sign — either nothing was learned or learning was ignored.

## Getting it past a sceptical board

Boards trained on fixed-scope cases may resist ranges. Frame it in their language:

- Emphasise that staged funding **reduces** their exposure — they risk only the next stage, not the whole programme.

- Show that the defined stop point is a risk control they don't get with a single big commitment.

- Point out that fixed-scope cases on uncertain work routinely overrun anyway; ranges just surface that risk early enough to manage.

- Bring evidence to every boundary so each continuation decision feels grounded, not faith-based.

Most boards become enthusiastic once they see they can stop a struggling project cheaply rather than discovering the overrun at the end.

## What still stays fixed

Hybrid does not mean everything floats. Keep firm:

- The **outcome and success measures** — these anchor the whole case.

- **Constraints** — hard regulatory, legal or deadline boundaries.

- **Tolerances** for the current stage.

- **The stop criteria** — the conditions under which you'd walk away.

Flexibility lives in scope and approach; discipline lives in outcomes and governance.

At neart.ai we build enterprise-grade PMO tooling, and the business cases that age well are the ones written as living instruments of decision-making rather than one-off approval documents. The case earns its keep at every boundary, not just at kickoff.

## Takeaway

Justify the outcome, not the feature list. Use value ranges with explicit assumptions, fund stage by stage with a defined stop point, and revisit the case at every boundary. You keep PRINCE2's discipline of continued justification while leaving Agile the room to discover the best path to the goal.