The Business Case - Case In Point

/

So you've surveyed your users, observed them doing their job, identified their pain points, outlined process and task flows, performed a gap analysis, read War and Peace...and, now, being the logical BA that you are, you've have come up with several options to improve the process, the workflow, the interface, etc. Now what? Depending on the size and structure of the organization, you may be asked to create a business case on behalf of the stakeholders.

The business case outlines the benefits of a proposed project/solution in terms of its expected ability to improve the business vs. the overall cost of the project.

Depositphotos_41001273_original.jpg

Preparing the Business Case

Since all business documents and templates vary in layout, length, and complexity depending on the type of business/industry, size and individual preference; ask if your organization has a particular business case format/template that they prefer to use. At a minimum you should be prepared to provide the following information:

Overview of the Opportunity and Proposed Solution

In a good novel the overview (e.g. executive summary) would be the 'hook' - something that grabs the reader's attention! Since your readers are, typically, the decision makers and financial backers of the project, start by giving them the benefits of the proposal. Be brief and to the point. Always, position the business case in terms of the positive impact - the problem itself should be secondary. Decision makers are always looking for projects that align with their overall goals and objectives, and improve their bottom line (e.g. Return on Investment - ROI), for example projects that:

  • Increase market share, brand, image
  • Provide new products/features
  • Improve processes, speed to market
  • Reduce operating expenses
  • Consolidate multiple platforms/resources
  • Improve customer satisfaction

Details of Proposed Solution

Building on your overview, you'll need to provide the nitty-gritty details that support the proposed project, including, but not limited to:

Definition/Background Information

  • Outline the problem/opportunity, how it has evolved, and how it was identified.
  • Identify the business goal of the project as it relates to the problem or opportunity.
  • Present the recommended preferred solution and selection reasons.
  • Provide the various alternative solutions/options that you have considered, investigated, compared and the reasons for rejection (include risks, benefits, limitations, costs, market assessment, etc.). Don't forget to include the option/cost of doing nothing at all.

Assumptions/Risks/Constraints

  • Outline any assumptions that are being made regarding the project (such as assuming the FDA approval of a drug, or non-repeal of a current law, etc.).
  • Identify any risks associated with the project and plans to mitigate those risks.
  • Identify any constraints to completing the project (e.g. staffing, equipment, timeframe, training, logistics, security, government agencies, etc.).

Scope/Plan

  • Outline the scope of the project and any dependencies.
  • Outline what is currently considered to be out-of-scope.
  • Define who/what will be impacted by the project (e.g. departments, roles, customers, functions, other projects, etc.).
  • If you are recommending a phased-in approach, list each phase (for example, Phase 1 may include a process change, Phase 2 may include new in-house technology, Phase 3 may implement mobile technology, etc.).
  • Estimate time to implement based on resources outlined in the financial section.
  • Define how the solution will be carried out (for example, will you outsource the project, buy an off-the-shelf software solution, home-grown solution, boot-strap solution, etc.).

Financial Implications

  • Gap analysis  - where are you vs. where you need to be based on the proposed project.
  • Cost of project (resources needed, research, software/hardware, licensing, marketing, training, etc.) vs. overall ROI, and other non-financial benefits.
  • Financial Implications of remaining static (e.g. doing nothing).

The business case will, typically, go trough several iterations with stakeholders before being presented for review/approval. The good news is that most of the information can be re-used in other documents, such as the project charter, the business requirements document, etc.

Remember, hook the decision makers by focusing on the benefits of a solution that is in line with the organization's goals and objectives - you just might have a best seller!