The business case practice I: purpose, development and options

The purpose of the business case practice is to establish mechanisms to judge whether a project is, and remains, desirable, viable and achievable, as a means of supporting decision-making about initial and continued investment. Those three words carry most of the weight. A project is desirable if its benefits outweigh its costs, dis-benefits and risks. It is viable if it can actually deliver the products needed. It is achievable if the products, once delivered, can produce the outcomes and benefits expected. A project can fail any one of these tests while passing the others.

PRIN-110 discussed the principle of continued business justification: a project must have a valid reason to start, that reason must remain valid throughout, and the justification must be recorded and approved. This lesson looks at the practice that makes the principle work: who writes the business case, how it develops over time, what it contains and how options are compared. Lesson 3 then covers investment appraisal, and lesson 4 covers benefits management.

Desirable, viable and achievable

The three tests map neatly onto the other practices. Desirability draws on the business case and risk practices. Viability draws heavily on plans: a project with no credible plan is not viable however attractive its benefits. Achievability draws on the people element and change management, which PRIN-120 covered: outputs that nobody uses deliver no benefits. A useful exam habit is to ask, when a scenario describes a problem with justification, which of the three tests is failing.

Outputs, outcomes and benefits

The business case rests on a chain of cause and effect. The project delivers outputs, which are its specialist products. People use the outputs, producing outcomes, which are the results of the change. Outcomes lead to benefits, which are measurable improvements that one or more stakeholders see as positive and which contribute to the organization's objectives. Some outcomes also produce dis-benefits, which are measurable results seen as negative by one or more stakeholders.

Separating these links matters because the project manager is responsible for outputs, but the benefits usually appear after the project has closed and depend on other people's behaviour. That is why the senior user, who represents those who will use the outputs, is accountable for specifying the benefits and for realizing them, while the executive is accountable for the business case as a whole.

Who is responsible

Responsibilities for the business case are spread across the project management team and the business layer. The table summarizes them in plain terms; the official manual gives the authoritative responsibility descriptions.

A frequent misunderstanding is that the project manager owns the business case because they write it. Writing is delegated; ownership is not. If the case weakens, it is the executive who must decide whether the project continues, and who answers to the business layer for that decision.

How the business case develops

The business case evolves through the project. It begins as a brief statement of reasons in the project mandate, becomes an outline business case in the project brief during starting up, becomes a detailed business case during initiation, is updated at every stage boundary and whenever an exception is considered, and is used after closure to confirm whether benefits have been realized.

What a business case contains

PRINCE2 provides guidance on the content of a business case, which organizations often adapt to their own templates. In plain terms, a typical business case covers an executive summary, the reasons for the project, the options considered, the expected benefits and dis-benefits, the timescale, the costs, an investment appraisal, the major risks and a recommendation. The test of a good business case is not its length but whether a decision-maker can see clearly why this option is recommended and what it will take to realize the benefits.

Options: do nothing, do minimum, do something

A business case should compare genuine options. PRINCE2 guidance commonly describes three kinds: do nothing, do minimum and do something. Do nothing is the baseline: what happens if the organization makes no change. It is rarely free, because problems usually grow. Do minimum is the least change that addresses the most pressing need. Do something covers one or more fuller solutions. Comparing options against the do nothing baseline shows what each option really adds.

Options can be compared first on qualitative criteria, which helps eliminate weak options before detailed appraisal. The code below scores the three options against weighted criteria that reflect the three tests of justification. Scoring is a structured way of recording judgment; it does not replace investment appraisal, but it makes assumptions visible and open to challenge.

weights = {"benefit": 0.35, "cost": 0.25, "deliverability": 0.20, "adoption": 0.20}
# scores 1 (poor) to 5 (excellent); for cost, 5 means cheapest
options = {
    "do nothing":   {"benefit": 1, "cost": 5, "deliverability": 5, "adoption": 5},
    "do minimum":   {"benefit": 3, "cost": 4, "deliverability": 4, "adoption": 4},
    "do something": {"benefit": 5, "cost": 2, "deliverability": 3, "adoption": 3},
}
for name, s in options.items():
    total = sum(weights[c] * s[c] for c in weights)
    print(f"{name:13} {total:.2f}")
# sensitivity: does the ranking change if benefit is weighted less?
alt = {"benefit": 0.25, "cost": 0.35, "deliverability": 0.20, "adoption": 0.20}
print("with cost weighted more:")
for name, s in options.items():
    print(f"{name:13} {sum(alt[c] * s[c] for c in alt):.2f}")

do nothing    3.60
do minimum    3.65
do something  3.45
with cost weighted more:
do nothing    4.00
do minimum    3.75
do something  3.15

With the original weights, do minimum scores 3.65, do nothing 3.60 and do something only 3.45. With cost weighted more heavily, do nothing rises to 4.00 and do something falls to 3.15. The scoring therefore does not settle the decision: it shows that the case for change depends on how much the organization values the benefits relative to cost, which is exactly the question investment appraisal in lesson 3 will answer with money rather than scores. Do nothing scoring well is a warning that the benefits of change need to be quantified convincingly.

The business case in the public sector

Public organizations add their own requirements to the business case. In the Government of Canada, the Treasury Board's Policy on Planning and Investment and its Directive on the Management of Projects and Programmes set expectations for how departments plan, approve and oversee projects, including assessing project complexity and risk and reporting on benefits. The directive has been revised since its first version, so check the current text on the Treasury Board Secretariat site. Provinces and municipalities have their own capital planning rules; many Canadian municipalities use multi-year capital budgets approved by council, which would govern a utility such as Ridgeline Water.

Whatever the framework, the PRINCE2 business case can usually be mapped onto it. Public templates may use different headings, require economic as well as financial analysis, or ask for alignment with strategic priorities, but the underlying questions are the same: why, which option, at what cost and with what benefits and risks.

Keeping the business case alive

The most common failure of the business case practice is not a poor initial document but a document that is never revisited. Costs rise, benefits are revised downward, a competitor launches a similar product, or a policy change removes the problem the project was solving. A business case that is not updated cannot tell the board when the project has stopped being worth doing. PRINCE2 makes the update a routine part of every stage boundary and every exception, so that the question is asked regularly rather than only when someone is brave enough to raise it.