Business Case

A Requirement is a condition or capability that must be met by a system or component to satisfy a contract, standard, specification, or other form of request.

Business Case

The Business Case represents the justification for purchase or construction of the product. The Business Case describes the problem which will be addressed and the desired outcomes of a solution including how the product will solve the problem or exploit/maximize an opportunity with cost benefits to justify spend/investment.
A Business Case qualifies the expected Business Value of significant investment.

Business Cases and Portfolio Requests are overlapping concepts. Both are essentially arguments for funding. In some organisations these are done via the creation of a Business Case. For very large/complex investments a Business Case may cover a number of Portfolio Requests, or spawn a number of investment options. In simpler cases Portfolio Requests and Business Cases may be the same thing.

As with Portfolio Requests, the business case should not describe product requirements in detail, instead it should place the problem and possible solutions in the context of the strategic business goals providing direct traceability to the business strategy and the delivery of business value. Business Cases include three critical pieces of information:
  1. a Problem Statement
  2. a set of Solution Options
  3. a Cost/Risk/Benefit Analysis
Because we can define business value using the POFL model, Return On Investment (ROI) becomes a simple formula:

Benefit (ROI) = Business Value – Cost of Implementation

Where business value is qualified in terms of the test above and cost of implementation is the cost of the product (and/or maintenance agreements) as well as the internal Delivery cost of deployment and support (as well as and configuration/customization costs).

Where business value is not defined in financial terms (e.g. in non-commercial organizations) we end up with a simple “Benefit vs. Cost of Implementation” equation which requires a subjective decision from Business Leaders: Is the benefit worth the cost? This decision should be entirely transparent to help people understand value in the organisation and work towards it.

Problem Statement

Often this is done in the form of an “elevator pitch” problem statement such as:

<solution name>

is for <Identify Customers>

who <express their needs>

our solution is <top level description of product>

that <enumerate top level features>

unlike <outline competition/alternatives>

As an example here’s the Problem Statement for Holistic Software Development:

Holistic Software Development

is for large/complex software organizations

who need to understand modern software engineering in a business context

our solution is to present a number of visual maps (the Big Picture and Small Picture) of software business backed up with practical detail avoiding academic or heavyweight process documentation

thatcovers people issues, business strategy, portfolio, programme and project management as well as architecture, technical delivery and integration

unlike simple small team based processes such as Scrum, RUP etc.

Solution Options – Cost/Risk/Benefit Analysis

The Business Case needs to describe a solution to the problem or ideally a set of solution options so that investment decisions can be made. Solution options need to be described in enough detail and clarity to differentiate from each other and to quantify in terms of cost/benefit/risk. Typically, a range of options will be presented from a minimal option to a fully featured option. A common approach is to list deliberately wrong options at the minimal and maximal ends of investment (e.g. the “do nothing” and “buy everything” options). If listing deliberately wrong options, then label them as such, otherwise business cases come across as the authors trying to trick or deceive the decision makers.
Each solution option needs to identify:
  • How much it will cost (in financial terms and in resource terms)
  • What its major risks are
  • What benefits can the business reasonably expect
  • Timescales for the above
  • What the Business Value, and therefore the Return on Investment, will be

Since these characteristics will be coarse estimations they should be presented as such and not given undue levels of detail to imply accuracy (e.g. a cost of $3.5M rather than $3,527,344).

The leading option, or indeed several reasonable options may be further elaborated into Portfolio Requests. If Portfolio Requests are not separately defined then the Business Case must cover the detail usually held in a Portfolio Request, especially the Build or Buy decision.

Portfolio Requests are simple expressions of a business requirement related to a Business Case. Portfolio requests elaborate a specific Business Case option with an indication of required funding and technical direction for Solution Architecture within the context of Enterprise Architecture. Sometimes Portfolio Requests will be to change the Enterprise Architecture.

Business Cases and Portfolio Requests are overlapping concepts. Both are essentially arguments for funding. In some organisations these are done via the creation of a Business Case. For very large/complex investments a Business Case may cover a number of Portfolio Requests, or spawn a number of investment options. In simpler cases Portfolio Requests and Business Cases may be the same thing.

Recommendations

As well as avoiding false accuracy, if possible avoid outlining business cases for excessive budget proportions over many years. Industry evidence shows that large scale long term IT projects typically fail. If very large scale investment is necessary to meet strategic goals, then break up the work into a number of smaller portfolio requests/business cases aligned to Strategic Goals and monitored via Executive Reporting to assure cohesion.

A common mistake we’ve seen in Business Cases is to compare solution options against a hypothetical case and then derive detailed information on savings/benefits etc. Hypothetical cases might be useful to illustrate an alternative but they are simply made up, detailed comparison is fundamentally flawed and is an expression of cognitive bias on behalf of the author.

Elaborated Business Case options, as with Portfolio Requests, require a foundation in architectural reality. A good Business Case will require input from a Business Leader to back the case for funding and an experienced Architect to back the case for technical feasibility and ensure risk assessment is valid.

We recommend that Business Cases are reviewed by an independent body to remove excessive bias.

Having reviewed many historic business cases and the resulting projects/programmes in private and public sector clients we have discovered that we can identify how likely a project was to fail simply based on the business case. Key indicators for potential failure are:
  • Logical fallacies in the reasoning esp. false cause, strawman, black-or-white, composition/division and, of course, texas sharpshooter
  • Over-abstraction: Lack of grounding in technical reality
  • Mischaracterization: Treating business change problems as technical problems or vice-versa
  • Plain wrong: Incorrect understanding of development processes
  • Too big: The scope and timescales are large
  • Complexity: High complexity problems, by their nature are difficult. Chunking them up into large projects/programmes makes the problem harder.