Creating bulletproof business cases

Introduction

One of the top issues we hear from our training clients is that projects often get justified or initiated by solution. This usually means either no business case was done or an insufficient business case was created. The resulting solution then often doesn’t completely solve the underlying problem; re-work then results, and the ongoing pain the project was intended to address will continue.

Inadequate or non-existent business cases usually result in unclear project scope. This, in turn, often leads to scope creep, which results in rework, cost overruns, delays, and so forth. In addition, inappropriate approaches on projects often lead to rigid solutions, such as selecting a COTS (Commercial Off-the-Shelf) package when a custom solution is warranted. Missing or ineffective business cases also tend to cause numerous changes and time and cost overruns, because the product requirements are often not clear up front.

Perhaps worst of all is the scrapping of projects due to loss of sponsor/stakeholder support, costs exceeding perceived benefits, and business changes. The only thing worse is finishing a project only to have the end-product not get used because the solution did not mesh with the business needs. The net effects of cancelled projects and unused products are wasted investments, lost opportunity costs, and more pain and frustration.

The general challenge addressed by this paper is the problem of projects not meeting business needs. Projects should help the business solve its problems, not continue to live with “pain” or missed opportunities that could have been addressed by the right project at the right time. This paper will address these issues by presenting:

1. A short overview of business cases
2. Various aspects of analyzing business needs
3. Recommending solutions with a feasible approach
4. Extensive coverage of cost-justifying projects, including cost-benefit analysis
5. Pitfalls to avoid when recommending projects.

We also provide numerous tips for functioning as a management consultant as you prepare your bulletproof business cases.

Overview of Business Cases

To begin, here is a textbook definition of a business case, which we will use throughout this paper:

“A document written for executive decision makers, assessing the present and future business value and risks related to a current ... investment opportunity.” (Keen & Digrius, 2003, p. xii).

A formal approach to creating business cases is laid out in A Guide to the Business Analysis Body of Knowledge (BABOK^® Guide), specifically in the Enterprise Analysis Knowledge Area. Following are the five tasks in Enterprise Analysis, all of which deal with the pre-project analysis of business needs. (IIBA, 2009, p. 81); they range from understanding the business need to determining solution approach and scope, and finally, the creation of a business case. All the tasks lead up to the business case, which are as follows:

• Define Business Need
• Assess Capability Gaps
• Determine Solution Approach
• Define Solution Scope
• Define Business Case

Practical Approach: SARIE

A more informal and practical method that has served our company and others for years, is the SARIE approach to business cases.

This approach ranges from capturing the true business need and underlying root causes, through a recommended solution and implementation approach, to a cost-benefit evaluation. Here is what SARIE stands for:

• Define Situation
• Analyze Situation
• Propose a Recommendation
• Plan Implementation
• Evaluate the Solution

The SARIE method supports the analysis of an organization’s internal strengths and weaknesses and external opportunities and threats, known as a SWOT analysis. Initiatives are undertaken to take advantage of strengths and opportunities to compensate for strengths and threats. These strengths, weaknesses, opportunities, and threats often are addressed in the situation as part of the business need.

Mapping SARIE to Enterprise Analysis

SARIE compares closely with the Enterprise Analysis Knowledge Area of the BABOK^® Guide. For your information, Exhibit 1 below shows a mapping of SARIE to Enterprise Analysis tasks; they differ mostly in their order. So, for example, the S part of SARIE is what the BABOK Guide^® calls “Define Business Need.” (IIBA, 2009, p. 81). At the other end, the E in SARIE matches the “Define Business Case” task.

Exhibit 1: Mapping SARIE to the Formal Enterprise Analysis Knowledge Area

We will see throughout the rest of this paper how each step of SARIE can help you plan and create bulletproof business cases.

SARIE: S – Situation

The Situation step identifies the business need for a change, and if appropriate, ultimately for a project. The Situation includes an understanding of business problems and opportunities. We feel it is essential to nail down the accurate situation before going on to analyze it or recommending anything to address the business needs.

Business Need: Situation Statement

A great way to document business need/situation is through a Situation/Problem statement. The format for a situation statement is:

Situation Statement:

• Problem (or opportunity) of “a”
• Has the Effect of “b”
• With the Impact of “c”

Following is an example of a fictitious company called Speedy Mortgage. Like many initiatives, they got started on an effort to automate their mortgage application process. Before diving into a charter or plan, though, the project manager, Ellie, decided to use SARIE to help prepare a formal business case. The first project she did was to study the business need and understand the impact to the business. Here is her situation statement:

Mortgage applications at Speedy Mortgage require, on average, 45 days to process, delaying their approval and final closing at an estimated cost of US$100 per closed loan. Delays also cause 5% of loans to be abandoned, losing US$10,000 revenue per loan, or US$1.2 million per year.

The problem, as Ellie saw it, was the delays in mortgage application processing, which affected the business by resulting in higher costs and increased abandoned loans. The ultimate impact to Speedy Mortgage is the cost of US1.2 million per year. Later, we will see how the financial impact from the Situation statement can help with a cost-benefit analysis.

SARIE: A – Analyze

A bulletproof business case solves the right problem. The next part of SARIE is to determine the root cause of a problem or the main drivers of an opportunity. Namely, the “A” stage of SARIE focuses on analyzing why the problem is happening in enough detail to be able to formulate recommendations to fix the problem or take advantage of an opportunity.

Below are seven industry-standard tools and techniques that are effective in getting to the root cause. There are others, to be sure, but we have found this group to be practical and effective for ferreting out the underlying root cause of any business situation. The outputs from the tools also become valuable appendices in your business case, which will support your recommendations.

The tools are roughly two types: high level and detailed. We recommend you start with these high-level techniques to get started:

• 5 “Whys” – ask “why?” up to 5 times to get to the true root cause. (5 Whys, nd)
• Mind Maps start with a problem and branch out to find causes (useful with the “5 Whys” technique).
• Fishbone Diagrams help find the root causes of problems by using major categories (compared to the Mind Map, which is a more free-form technique).
• Process Diagrams to look for root causes in processes that contribute to the problem.

Once we have discovered the most likely root causes, it’s time to get detailed measures of those areas. The following techniques help analyze the measures:

• Interrelationship Diagrams are a special kind of cause-and-effect diagram that can examine the causes uncovered by fishbones and mind maps, and then inter-relate them. Causes that create the most effects are the ones to fix first.
• Pareto diagrams show the most significant contributors to a problem, in order of their frequency. Based on the 80/20 principle, they point out quickly what should be fixed first to significantly address a business need (80% of the problems are caused by 20% of the factors).
• Scatter diagrams show trends and correlations between two sets of variables. Correlation means that as one variable changes, the other variable changes as well. Scatter diagrams can point in the direction of further exploration for the root cause of a problem.

SARIE: R – Recommendation

Once we have confidently determined the root causes of a problem, we can then find the right solution scope and approach to address the business need. The solution scope and approach map to the “R” and “I” parts of SARIE, namely the scope of what is being Recommended, and the approach to implementing it.

What is Solution Scope?

We will use the term “solution,” in the way the BABOK^® Guide uses it, to mean the deliverables that must be produced and how they will be produced. Beside the deliverables to be produced, the solution may also include scope of the analysis, any enabling capabilities, and the chunks of how it will be released (IIBA, 2009, p. 232).

• Scope of analysis – what is the extent of the business area to be analyzed and the functions/processes added or changed?
• Capabilities supported – what are the decomposed processes, organization units, and any software applications that will be affected?
• Releases or Iterations – will the solution be delivered in phases or releases?
• Enablers – what supporting capabilities need to be delivered to ensure our solution will work?

Determining Recommendations

A good recommendation to resolve a business situation will address the business need and root cause(s) uncovered in the previous SARIE steps S and A. Typically, the act of defining a situation and the work to discover the underlying cause(s) will suggest one or more recommendations. Any potential solutions should be further refined by examining the approach to implementing them, which is covered below in the “I” phase.

A challenge in creating solid business cases is to resist the temptation to “jump to a solution.” This common phenomenon is also known as “satisficing” (satisfy + suffice), which is defined as the first or easiest solution that seems to satisfy the problem.

Techniques to Define Scope

To ensure your business case includes the proper scope and all relevant costs, make sure you decompose the solution in enough detail to discover the dependencies and enablers needed. There are various ways to do this, and a few standard techniques are usually sufficient.

Functional Decomposition. A Work Breakdown Structure type of approach is standard and works well to refine the scope enough to understand the dependencies and other enabling deliverables needed. Detailed scope decomposition is normally a project planning activity, and our advice is to decompose the scope just enough to understand the major deliverables needed.

Scope Diagrams. Scope diagram techniques provide a visual depiction of the elements involved, which help us grasp the “big picture.” They can also help uncover missing elements, particularly interfaces to existing or new system components. Use case and other context-type diagrams are excellent tools to help visually depict the solution scope. See Exhibit 2 for an example use case diagram. The bubbles in the model represent functions to be parts of the solution scope, and the lines between the bubbles and the outer symbols are needed interfaces. The symbols outside the box are “actors” who provide inputs to and/or use outputs from the system.

A recent project of ours was helped considerably by using a scope diagram to brainstorm possible missing interfaces and the functions needed to create a new Training Management System. We had not initially created a scope diagram, but instead created one just before signing a final development contract. Fortunately, the scope diagram helped us find a number of missing functions and interfaces that would have gone undocumented without it. The tool also made sure we included the missing pieces in our contract and avoided some costly rework later.

Exhibit 2: Use Case Diagram as a Scope Diagram

User Stories. Finally, tools like user stories are also appropriate in a business case to elaborate on the solution. They document the scenarios from a business viewpoint of how a solution should behave in response to various situations. See Exhibit 3 for an example. It shows the role (“mortgage broker”), the goal (“instant notification of an application”), and the motivation (“receive timely interest rate quotes”) for the scenario.

Exhibit 3: User Story as a Scope Component

SARIE: I – Implementation

The “I” in SARIE is the Implementation stage, which is another way of describing at a high level how the solution is to be delivered. Think of it as the approach for delivering the solution, including the types and numbers of projects proposed in the Recommendation part of the business case.

The approach covers high-level considerations like buy versus build, in-sourcing or outsourcing, modifying existing systems and processes or not, and includes analyzing which approach is the most feasible one to address the business need. We will return to feasibility shortly.

Alternative Approaches

Once we know the problem to be solved and the deliverables to be added, we can then generate and analyze alternative approaches. Although many organizations choose the approach before undertaking a business case, our feeling is that the preferred way is to consider alternatives and recommend the best one.

To help in considering the various alternatives, we suggest using the technique of “associated brainstorming” to generate alternative approaches. This technique is especially helpful when people are locked into a solution, or tend to favor certain approaches, like software packages. From the generated approaches, a technique like Decision Analysis or Weighted Ranking (see below) can help determine and recommend the preferred approach.

Solution Analysis

To prevent the ever-common problem of “jumping to a solution,” it is important to carefully examine and understand both the recommended deliverables and their implementation. We will use the term solution analysis for short to refer to this. To analyze the best solution scope and approach, two techniques are especially helpful: Decision Trees and Weighted Ranking matrices.

Decision trees provide some objectivity and lead to an Expected Monetary Value (EMV) of alternative decision paths. They take risk into account by showing the alternative paths and outcomes if the risks materialize.

In the example shown in Exhibit 4, the “Build” path leads to a better EMV of US$287,000 versus the “Buy” path, with a lower EMV of US$265,000. At this stage, it appears to be the better approach, although there may be other factors, such as constraints and other costs/benefits that haven’t been investigated yet.

Exhibit 4: Decision Tree Example to Help Select Recommended Approach

Weighted Ranking Matrices. When we have multiple recommendations and/or approaches to choose from, we can rank-order them. Weighted ranking uses the technique of pair-compare voting based on specific criteria to formulate a decision or recommendation. It should use criteria relevant to the decision, so be sure to use the criteria important to the executives who will be making decisions on which projects to undertake. In other words, we should focus on the benefits, not the features when doing this type of analysis.

Feasibility Studies

Another technique that helps to solidify a proposed Recommendation and Implementation is a Feasibility Study. Feasibility analysis is another way to generate and analyze potential solutions and approaches. A feasibility study is a common and accepted technique used in creating a business case. We recommend a separate project for creating a business case and not burying a feasibility study in the project itself.

A major benefit of Feasibility Studies is to save the money and trouble of a full cost-justification of a project that may not be feasible. In other words, we perform a feasibility analysis before expending more time and energy on the business case, especially the rigors of researching costs and benefits.

These studies may generate additional approaches to analyze and rank order, so the R & I stages of SARIE are often performed iteratively. Here are some factors we consider when conducting feasibility analysis and it is called the TELOS framework (Feasibility Study, 2011, ¶2), referencing the first letters of the mnemonic:

Technology Feasibility - Projects are often driven by constraints of existing platforms, databases, networks, and so forth. Is the approach technically feasible within the constraints?

Economic Feasibility - This is the preliminary cost-benefit analysis. Does the approach seem affordable? Is the pay-back period quick enough?

Legal Feasibility - Are we violating any laws with the approach? Is it ethical?

Operational Feasibility -How well does the solution meet the business needs? How well does it match our high-level requirements?

Schedule Feasibility -Will the approach accomplish what we need when we need it?

SARIE: E – Evaluation

Remember that a business case should facilitate decision making by executives to evaluate how proposed projects will meet the business needs and they should include cost-benefit and other information to support the proposal. When used correctly, the executive team will then judge how cost-effectively the proposed solution meets the business needs compared with alternative proposals. The cost-benefit analysis and measurement map directly to the “E” part of SARIE, namely the Evaluation stage.

Essential Components of a Business Case

An actual business case template may have 10 to 20 sections in it, depending on the organization. All of the SARIE elements covered so far should be included, such as the outputs of the techniques like root cause analysis, weighted rankings, and feasibility analysis.

Rather than covering every other possible inclusion, we will focus the remainder of our discussion on three elements not previously addressed. One essential element to include in a bulletproof business case is an initial risk assessment. Mitigating the risks may lead to increased costs or perhaps even abandoning a business case if the risks are judged to be too great. Bulletproof business cases should include risks such as solution feasibility and technical, financial, and organizational risks. Assume that the decision makers have a list of risks in their heads and they will challenge an overly optimistic business case.

Costs and benefits are the other two essential components of a bulletproof business case. Essentially, we gather the benefits from a business owner, line them up against the costs, and if benefits outweigh costs, we have a potential business case. NOTE: without further explanation, this might be confusing. It is to me!

Benefits

Benefits are obtained from business owners, but how we present them can make or break a business case. Our proposals should include mostly tangible benefits, and when backed with solid supporting measures, help create a bulletproof business case. Tangible benefits can be “monetized,” such as sales and market growth, reduced costs, and fewer defects.

Intangible benefits_are acceptable if the business owner does not want to convert them to tangible benefits and judges them to be significant and in line with the organization’s strategy. Increased customer satisfaction, improved employee morale, and corporate image, although not directly monetary, might still be valuable to the organization.

Costs

Costs are easier to obtain, just by their very nature. It is easier to monetize them when you have vendor RFPs and other inputs to base them on. Examples include the cost of software packages, custom programming, equipment, labor, advertising, government fees, and so forth. One source recommends you spend onefourth of your cost-benefit research time on costs and three fourths of your cost-benefit time on benefits (Keen & Digrius, 2003, p. 64).

Financial Analysis

To repeat, Decision Trees and Weighted Ranking Matrices can help us choose the recommended solution approach and form the final recommendations. These tools are partly financial and partly subjective.

Business cases are strengthened considerably by including solid financial tools, such as Net Present Value, Rate of Return, and Pay-Back Period. Different organizations tend to favor and use specific tools, and we may want to engage help from our organizations’ financial analysts. This paper covers four of the most commonly used financial formulas and shows an example of each below. First, let’s cover two basic financial tools that are easy to compute, but aren’t quite as accurate as the second set of tools.

Pay Back Period (PBP). Also known as “Break-Even Point,” this is the time needed to recover an investment, before positive net benefits begin. Organizations may have a standard “hurdle rate,” as it is sometimes called, that states that a Pay Back Period must be less than x months or y years. A weakness of this approach is that it does not factor ongoing costs into the calculation. It also ignores the time-value of money, which takes into account that a dollar today is worth more than a dollar a year from now; however, it is intuitive, easy to understand, and easy to compute.

Exhibit 5 shows a graphic example of PBP, with 1.35 years to pay back the initial investment. If Speedy Mortgage's hurdle rate is one year or less for a Pay Back Period, then this measure does not meet the criteria.

Exhibit 5: Pay-Back Period Example

Return on Investment (ROI). This measure is an average of all net benefits divided by the initial project cost. It is also easy to compute, and like the Pay Back period, it ignores the lifetime costs of the investment, which may or may not always be known. In our example business case, there are average, yearly projected net benefits over three years of US$371,000 divided by a US$1,25 million initial cost. The resulting ROI calculates to 29.7%. If Speedy Mortgage has a hurdle rate of 25% ROI for a three year period, then a 29.7% ROI in the example will pass that threshold.

Internal Rate of Return (IRR). This is a more exacting calculation than ROI and is used to calculate the hypothetical annual yield of an investment (i.e., the annual growth rate of an investment, like a stock or mutual fund). Microsoft Excel has a function for this, so you don't have to be a math genius to use it.

Using the Excel formula, our example business case has an IRR of 58% and if current interest rates are at 5%, the project would be a good investment. The example of IRR is fairly high, and may be enough to overcome the longer than desired Pay-Back Period.

Net Present Value (NPV). This metric is the estimated future value a project might bring, less its calculated value today (“present value”) of what the future value will be. NPV is the value of a dollar today compared with the value of that same dollar in the future, taking inflation and returns into account. Because you can factor a minimum interest rate into this formula, any positive NPV is considered a good investment; Excel has a function for this, too.

Using the Excel formula, the business case for Speedy Mortgage shows a Net Present Value of $1.2 million. Because any positive NPV is a good investment, this example looks like a very good one for Speedy Mortgage.

Benefit Identification

Exhibit 6 below is an example worksheet for handling the financial analysis for a bulletproof business case. Here is a summary of the financial projections. Note:

• The simple measures on the top left: Pay-back period and ROI. The Pay-back period is moderately short, although it may be longer than Speedy Mortgage's hurdle rate, but the ROI may exceed the company’s hurdle of 25% ROI. Both calculations were done using simple Excel formulas.
• The more complex calculations on the right show a good IRR, which is above Speedy Mortgage's hurdle rate, and a strong NPV. These two numbers were created with Excel’s IRR and NPV built-in formulas.

Exhibit 6: Financial Analysis Worksheet Example

Ten Tips for Presenting a Business Case

Now that we’ve covered the need for business cases and the important components of them, let’s explore how to present them. Following is a list of tips for preparing and presenting our bulletproof business cases and the pitfalls to avoid.

1. Treat every business case as a project. Projects need sponsors, scope, and stakeholders. If we ignore key stakeholders, they may raise objections when we present the business case and may end up being saboteurs. We need to avoid owning the solution or decision; the business is the ultimate owner.
2. Avoid leading with a solution. Always define the situation first! Analyze why next, THEN a recommended solution is appropriate. Better yet, avoid responding to a Solution Request! We project managers and business analysts are often given solutions. When presented with a solution, we need to ask: “What business problem are we solving?”
3. Avoid “satisficing,” or finding the easy solution or the one we intuitively favor. Executives want us to find the “low hanging fruit,” a popular term used today, but the right solution takes time to formulate. The result of this pitfall is that the end-product won’t meet the business needs completely and may get cancelled or not used. To avoid “jumping to a solution,” we need to make sure that we use logical, step-by-step arguments, and that our recommendations address all the elements of the business need and its root causes.
4. Create a SARIE business case:

   •   S – What is the current state/business need?

   •   A – What is causing the business need and what is missing today?

   •   R – What do you recommend?

   •   I – How will it be implemented? What is the approach?

   •   E – How will decision-makers evaluate your business case?

5. Costs. Focus on the top five costs (Keen & Digrius, 2003, p. 65). Remember that we usually spend one quarter of our cost-benefit analysis time on costs. When appropriate, we need to include the total cost of ownership in the annual costs. Some financial formulas we looked at use future costs, like IRR and NPV. Use them.
6. Ensure that the benefits align with the organization's goals and objectives. We need to work with the business owner to articulate tangible benefits. We need to assume the audience wants mostly tangible benefits, but will listen to intangibles, if linked to the strategic direction of the organization. We need to find the criteria of importance for decision makers and base our benefits on them. In addition, we need to avoid the “Feature Fallacy.” All too often, projects stress the features of a solution, like: “mobile-enabled” or “one point of loan review,” instead of saying “expanded market” or “removes duplication and lowers costs,” which are the business benefits.
7. Avoid phony benefit numbers and admit it when no data are available. Intangible benefits may make the case, particularly when they align with the SWOT analysis, such as offering a product or service that allows us to compete in the marketplace.
8. Presenting a Business Case. Before presenting, we need to do all our homework: be prepared. A major component of influence is preparation, which helps us build the trust we need and gives us the confidence and courage we need to make a good presentation.
9. Assume the audience is impatient and provide executive summaries up front. We find it helpful to include alternatives along with our recommendation. We assume our decision makers are always thinking of alternatives, especially cheaper ones, and we need to work to disarm their objections in advance.
10. Handling objections. Remember that we are advising the organization with our well-thought out recommendation. Don’t take rejection personally. If your business case is rejected, ask:

    •   Did I work closely with the business owner to develop the business case?

    •   Do I understand the “objections?”

    •   Can I address them to meet stakeholder needs? If I can, the final product will be even better.

    •   Am I enthusiastic enough? Courage helps with this, but so does a real belief in what you are proposing.

    •   Have I given stakeholders enough time to think about the proposal before asking for a decision?

    •   How can I best support the business owner? Should I advise the business owner to walk away (at least for now), or, do we act like a pit bull that grabs on to a leg and won’t let go?

Final Thoughts

There are many impediments to creating bulletproof business cases. Many organizations don’t even bother to create them or have a formal process for doing so. As you and your organization grow in your desire and opportunity to create formal business cases, we invite you to adopt the content and process outlined in this article. If you do so, we feel confident that you will have bulletproof business cases as a result. Some of the benefits we can expect from improved business cases include:

• Increased likelihood that project benefits will be realized.
• Reduced political friction through greater transparency and objectiveness.
• Reduced time in evaluating and prioritizing projects.
• Closer match of projects to strategy, increasing the odds of selection.
• Increased likelihood of solving the right problems, keeping them from recurring.

Let us know how your efforts go, especially what worked well for you and what could be added to our approach. Happy bulletproofing!