Business Cases

Goal

A business case is the answer to a decision question: is this change worth what it costs and in what form? The BABOK defines it as a justification for a course of action, based on the benefits expected from the proposed solution and compared with the cost, the effort and the other considerations attached to acquiring and operating it.

Two decisions rest on it. The first is the go-ahead: does the organisation commit the money and the people? The second is the choice between alternatives, each described on the same grid. HERMES places this work in the initiation phase and makes it the precondition for the project management plan and the execution order.

PMI draws a line that practice often blurs. The business case justifies the investment, the project charter authorises it. The PMBOK Guide, in its sixth edition, makes it a documented economic feasibility study, prepared before the project starts, read again after closure and kept as the reference for judging the project's success against the objectives it announced. Where the two documents merge, the question of why disappears as soon as the project has a number and a budget.

The deliverable is the document itself and, at its centre, the comparison of alternatives. The document gives enough detail to inform the decision and request approval, without entering into how the solution will be built: the how belongs to the project the decision will trigger. One business case may trigger several initiatives.

Usage

When to use it

• Releasing an investment budget: a decision-making body has to commit funds on a written submission.
• Several plausible alternatives: technologies, processes, business models, acquisition routes or timings to be separated on one grid.
• Initiation phase of a project: HERMES makes the execution order conditional on the study.
• A public tender to prepare: the document supplies the estimate, the scope and the criteria that will feed the call for tenders.
• Review milestone during an initiative: re-measure the desired outcomes and replay the assumptions before releasing the next tranche.

When not to use it

• A stake too small for the effort asked: cost the single option with a one-page cost-benefit analysis.
• A change imposed by law with no room to manoeuvre: no alternatives to separate, frame the deadline then move on to the requirements.

Description

The four elements

The need assessment is the driver of the document. It names the problem to be solved or the opportunity to be taken, then the business objective it serves. Tying it to a strategy gives everything that follows its deciding criterion: without it, the comparison of alternatives shrinks to a ranking by cost, where doing nothing always wins.

The desired outcomes describe the state of the organisation once the need is met. They carry measures, without which nobody will be able to say whether the document kept its promises. They are independent of the recommended solution and are therefore written before the alternatives are examined: the degree to which each alternative achieves them is what will point to the recommendation. And they are revisited at defined milestones and at the end of the initiative, to judge the success of the document and of the solution. The BABOK points back to the technique from its §8.1 "Measure Solution Performance", where the business case serves to define the business objectives and the performance measures of a proposed solution.

Assessing the alternatives lists the possible solutions and compares them. Alternatives may bear on different technologies, processes or business models, but also on ways of acquiring them and on implementation timings. Budget, schedule and regulation constrain them. The "do nothing" alternative is assessed like the others: it is the reference against which every benefit is measured, and it carries a cost the status quo conceals.

The recommended solution describes the most desirable way of dealing with the problem, with enough detail for the decision makers to understand what they are approving. It often carries estimates of cost and duration. It restates the measurable benefits and outcomes that will allow the performance of the delivered solution to be judged after go-live and during operation.

Four axes for each alternative

Scope defines the alternative proposed. It is described through organisational boundaries, system boundaries, business processes, product lines or geographic regions. It states what is included as well as what is excluded. The scopes of two alternatives often overlap without coinciding, which is enough to distort a cost comparison made without reading them.

Feasibility is judged on two levels. The organisational level covers the knowledge, the skills and the capacity available, capacity being most often the limiting factor in a Swiss administration or SME, where the same people hold both operations and the project. The technical level covers the maturity of the technologies proposed and the organisation's experience of them.

Assumptions, risks and constraints are documented alternative by alternative. An assumption is a fact agreed by all parties that may influence the initiative; a constraint is a limitation that restricts the possible alternatives; a risk is a potential problem with a negative impact. Writing them down creates realistic expectations and a shared understanding. The document also finds there what will have to be replayed the day an assumption fails. The project's risk register will take over those of the chosen alternative, which is the subject of risk analysis and management.

Financial analysis and value assessment estimate the cost of implementing and operating the alternative, then the quantified financial benefit it brings. Non-financial benefits count in the same way: staff morale, flexibility in responding to change, customer satisfaction or reduced exposure to risk. They are tied back to the strategic objectives, which lets them be weighed against the rest. A benefit with no column in francs disappears from the grid if it is not named there. Where qualitative criteria have to be weighted to separate the alternatives, a multi-criteria decision analysis runs that comparison inside this axis.

Running the work

1. Establish the need
   Status report, problem or opportunity, business objective served. This step is run with the stakeholders, often in a workshop.
2. Set the desired outcomes
   An indicator, a target value, a deadline and the source that will measure them, for each one. This step comes before the alternatives are examined.
3. List the alternatives
   Do nothing first, then the others. Sweep the BABOK's axes of variation so as not to stop at the two options already on the table.
4. Assess each alternative on the four axes
   An alternative that is dropped stays in the document with the reason it was dropped.
5. Cost them on a common basis
   Same horizon, same cost categories, same treatment of recurring benefits. The net cost of an alternative, its costs less its quantified benefits over the horizon chosen, is what makes the columns comparable. Beyond three or four years, discount the flows before adding them up, which is the subject of net present value.
6. Recommend
   Name the chosen alternative and the reasoning that leads to it, at the head of the document. A three-paragraph summary is enough for a committee: the subject and the findings, the alternatives and how far apart they are, the recommendation and the decision asked for.
7. Get the decision, then keep the document
   The decision is recorded in the document. At the following milestones, the desired outcomes are measured again and the assumptions proved wrong are corrected.

The same document under three frames

A Swiss business analyst will meet three structures for one artefact.

The four elements and the five cases are not one taxonomy under two names. HM Treasury's Management case, which covers the delivery arrangements, the governance and the tracking of benefits, has no matching element in the BABOK; the BABOK's financial analysis splits between the Economic case (best economic value) and the Financial case (affordability). HERMES adds the choice of the project scenario to the document.

Pitfalls

The dominant pitfall is reversing the order: choosing the solution, then writing the desired outcomes that justify it. The document stays presentable and decides nothing: its criterion was adjusted after the fact to the solution chosen. The symptom shows on reading: desired outcomes that name a technology, a supplier or a feature instead of a measurable effect on the organisation. The BABOK's desired outcomes are independent of the recommended solution in order to prevent this.

The second pitfall is the missing "do nothing" column. With no reference, no benefit means anything: time saved at the counter is measured only against the time the counter consumes today. The omission favours the status quo, whose costs are already budgeted and therefore invisible, against alternatives whose every franc is new and visible spending.

The third pitfall is the document abandoned once the funding is secured. The BABOK counts it among the limitations of the technique: the document that was to guide decisions throughout the initiative stops being opened. The PMBOK Guide makes the opposite demand in the principle "Focus on Value" of its seventh edition: financial performance is assessed continuously against the business case, and where the gap persists or the project is unlikely to deliver the value expected, ending it can be the best decision. A document kept current makes that decision possible without a trial.

The fourth pitfall is author bias, also noted by the BABOK. The document is often written by someone who already carries one option, and the assumptions favourable to that option go in without being discussed. Three practices answer it: have the rival alternative costed by someone else, write the estimating method next to each amount and have the assumptions reviewed by a department that gains nothing from the decision.

The fifth pitfall lies in volume: a long document drowns its recommendation, when the effort expected follows the value at stake. An investment of CHF 50'000 does not deserve the same thickness as a CHF 5 million programme.

AI considerations

The most solid contribution a language model makes is generating alternatives. A team produces two, the one it knows and the one from the supplier who called; given the need and the constraints, the model proposes others along the BABOK's axes of variation, among them the acquisition routes and the alternative timings, the two most often forgotten. It is useful as a challenger too: asking it to attack the preferred alternative and to list the assumptions that bring it down answers author bias. It also writes the three-paragraph summary for the committee correctly, once the inputs are supplied.

What it must not do has to do with where the figures come from and with local knowledge. An amount produced with no traceable reasoning is more dangerous than an empty cell: it passes the review because it is presented with confidence, and the whole document then rests on it. Organisational feasibility escapes the model, because knowing whether the municipality's IT department can hold 0.4 FTE for nine months rests on knowledge nobody has written down. The data that feeds the costing is sensitive: salaries, supplier contracts, sealed bids. It is not deposited with an external service without checking what the organisation allows. The recommendation itself is an act of judgement that commits whoever signs it before the decision-making body.

Examples

A Vaud municipality of 9'200 inhabitants has to replace the software of its residents' register, whose vendor is ending maintenance in eighteen months. The desired outcomes were set before the alternatives were examined: bring the handling time for an arrival notification at the counter down from 12 to 6 minutes within twelve months of go-live, raise to 40% the share of notifications filed online at eighteen months and record no rejected data delivery to the canton over three consecutive quarters. The comparison of alternatives runs over a five-year horizon, with go-live in year 1.

What the grid makes visible is the comparison on equal columns, "do nothing" included. Without that column, the CHF 130'000 the municipality will spend on maintenance and re-keying whatever it decides would appear nowhere, the two alternatives would read as new spending and the most expensive decision would pass for the most prudent. Alternative B carries the highest gross cost of the three (CHF 190'000) and the lowest net cost (CHF 58'000): it is this second figure, set against the CHF 130'000 of the status quo, that the recommendation invokes. The row on achievement of the desired outcomes does the rest of the work, dropping alternative A on a criterion written before the alternatives existed.

Visualisations

The comparison grid is the artefact itself: rendered in HTML rather than as an image, it stays readable on a phone, selectable and accessible. A reviewer recomputes each net cost there from the entries in that column alone. The chain of the four elements shows the order of the work, from the need to the recommendation, with the return of the desired outcomes to the measurement of the delivered solution.

Cost

Tooling

The spreadsheet carries the costing: one tab per alternative, the same frame of cost and benefit lines, a net cost calculated by formula so that the grid recomputes when an assumption changes. The document itself almost always follows an imposed template. HERMES publishes the templates for its outcomes, the study among them, and most Swiss cantonal and municipal administrations as well as the large companies impose their own: taking it as it stands avoids an argument about form at the moment of decision. A risk register, held in a spreadsheet or in the project management tool, collects the axis of assumptions, risks and constraints and passes to the project if the decision is positive. Organisations that compare dozens of documents hold them in a portfolio management tool, where the grid becomes a structured record and where the trade-offs are made between documents. A whiteboard, physical or shared, remains the tool for producing alternatives in a workshop with the stakeholders.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.7 Business Cases: the definition of the business case as a justification for a course of action based on the benefits compared with the costs and the efforts, the rule of proportion between the effort invested and the value at stake, the four elements and the four axes for assessing an alternative, the requirement to assess the "do nothing" alternative, the independence of the desired outcomes from the recommended solution and their revisiting at milestones, the pointer to the technique from §8.1 "Measure Solution Performance", as well as the limitations of the technique: the bias of authors, the document rarely updated once funding is secured and the cost and benefit assumptions that prove invalid on closer investigation.
• HM Treasury, Guidance on developing business cases for projects and programmes: the Five Case Model and its five cases, strategic, economic, commercial, financial and management, as the reference structure of a public investment submission and the role of the Management case, which has no direct equivalent among the BABOK's elements.
• Swiss Confederation, Federal Chancellery, HERMES 2022, outcome Study: the study produced in the initiation phase, which corresponds to the business case, shows the business benefit of the project and its link to the strategy of the core organisation, its content (background, objectives, rough requirements, solution options with cost/benefit considerations and risk assessment, proposal and decision on next steps) and its status as a precondition for the project management plan and the execution order.
• PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 6^th edition, §1.2.6.1: the definition of the business case as a documented economic feasibility study establishing the validity of the expected benefits, its preparation before the project starts and its review after closure, as well as its distinction from the project charter it feeds.
• PMI, The Standard for Project Management (PMBOK Guide, 7^th edition), principle "Focus on Value": financial performance is assessed continuously against the business case, and ending the project early becomes the best option when the value expected is unlikely to be delivered.