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.
- a Problem Statement
- a set of Solution Options
- a Cost/Risk/Benefit Analysis
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>
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
- 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.
- 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.