Business Case

Developed by Casper Stroem

Video 1: procurementacademy: Business Case - Definitions

Abstract

This article treats the subject Business Case within project management. The definitions of Business Case are defined with limitations for the subject. The intended audience for the article is students new to project management and needs to understand what a Business case contains and its relevance. Business Case is the document that defines whether or not a project is worth undertaking from the company perspective. A Business Case can be either pre-defined from a corporate level or initiated at project start. The Business Case is revisited and refined throughout the project duration. Within the initial phase of a project the Business Case is being defined and developed, but once the project progresses past the initiation stage, the Business Case is being maintained through the rest of the project. The Business Case is evaluated through a cost-benefit analysis, such as a payback period or Net Present Value(NPV) which is more comprehensive compared to the payback period analysis. The article will discuss relevant tools to Business Case and the relevant responsibilities when creating or working with a Business Case.

The Business case is defined by Murray,(2009) as a document that presents the optimum mix of information used to judge whether a project is desirable, viable and achievable, and therefore worthwhile investing in. A similar definition for a Business Case is made by Maylor (2010) ‘. . . justification for undertaking a project, in terms of evaluating the benefits, cost, and risk of alternative options and rationale for the preferred solution. Its purpose is to obtain management commitment and approval for investment in the project. The business case is owned by the sponsor.’

The main limitations of the Business Case lie within the people in the project team. In order for the Business Case to be utilized to its greatest potential, the people within the Project team has to use it as the main guidance document throughout the project and adjust it when required.

What is a Business Case

A Business Case is the reference point before, during, and after a project, the organization undertakes. A Business Case is a document that contains the justification for a Business to undertake a project as well as the value this project creates when completed. The Business Case needs to contain crucial information about the project such as:

• Reasons

• Options

• Benefits and dis-benefits

• Timescale

• Cost

• Major Risks

• Opportunities

According to Herman (2009) five serious problems arises if the organization do not have a Business Case for their projects.

(1) The organization wastes valuable resources on projects that don't help the organization achieve its objectives. This leaves fewer resources available for more valuable projects.

(2) The organization has no clear basis to prioritize projects, for establishing what is important. Without a Business Case—and some organization-wide agreed measure of “value”—there is no means of determining which projects are important, and which are less so. Many organizations use “the loudest voice” approach, in which the managers who yell the loudest (or who have more influence, or are more intimidating) get what they want—even when their projects have no relationship to the organization's objectives! The organization needs a more rational and effective means of allocating its limited resources. Without this the organization's strategy languishes with no clear assurance that the strategy is being progressed by any particular expenditure of resources.

(3) There is likely to be disappointment after the completion of the project, as the stakeholders wonder why the project is not giving the great results they imagined—very likely because the project manager didn't know what those expectations were, or was focusing predominantly on what was being built, rather than on how it would be used.

(4) No target is established for why the project's deliverables are being created—other than the meeting of technical specifications. This allows the project team to get over-engaged in technical details, losing sight of the goals of the project. At project completion, there is no clear way of determining whether the project delivered value. Both occur because no benefit goals were established before the project began.

(5) The organization has no opportunity to improve its project management maturity. One key learning from each project should be: “how well did the resource usage support the organization's goals?”

Types of Business Cases

A Business Case can take many forms. The following are several examples:

• ROI (Return On Investment): Spending time and money in development is expected to deliver far more money than went into the project.

• Strategic: The project supports the Organization's Strategy and/or Mission (which may not always be about short-term, or dollar-for-dollar returns).

• Investment: Developing new products in the laboratory, for eventual (“we hope”) expansion into money-making products.

• Values: This is a variation on Strategy/Mission—where the organization's social values are agreed, as part of the corporate culture, to be one of the organization's common expectations and goals.

• Research: “We'll probably lose money on this project, but we will learn a lot that will help us set the organization's future direction.”

• Efficiency: A variant of ROI, the project is done to improve the organization's operational processes.

• Compliance (Regulatory/Statutory/Fiduciary): A project is required for the organization to comply with external regulations.

Defining a Business Case

Figure 1: Six Star constraint model

When defining a Business Case the aim is to address all of the six areas shown in Figure 1. The six-star constraint is an expansion of the classical triple constraint. Maylor p. 184(2010) remains slightly cautios of the definition stated in the abstract for the article. The basic definition is useful, but assumes that there are always definable benefits, costs, that risks can be assessed, that there is a well-understood problem that needs 'solution' and that there a defined sponsor.

Executive Summary

Even though listed first both in this article and in the Business Case template this is the last section of a Business Case to be completed. The Executive Summary is quite simply a summary of all information on the Business Case. In this section general information about the issue needing addressing, and the proposed solution and outcome.

Reasons

The Reason or Reasons for a Business case is also known as the problem statement for the project. It describes why the project is being considered and the background that led the organization to consider the project in question. The Reasons can change the project due to change in circumstances so the project is not needed anymore or another option will be considered instead. Other relevant information to the Reasons will be things such as organizational impact describing the change within the tools, processes, and other relevant areas that the proposed project will incur. Addressing the Technology migration in this area is relevant, detailing a high-level overview of how the new data and tools will be implemented and the transfer of data from the legacy system.

Business Options

Defining the options there are always three main initial possible choices.

• Do nothing
• Do the minimum
• Do something

The above points are all considered when conceptualizing the different viable options in response to the Reason for undertaking the project and the outcome of each option. Multiple options are needed to understand why the selected option was chosen over the alternatives. The source for all of the options considered typically comes via a feasibility study done prior by the organization.

Expected Benefits and Drawbacks

Benefits are the expected value to be delivered by the project, measurable whenever possible. Dis-benefits are negatives to the organization, and the project would want to minimize them.

This section should also include:

(a) The level of benefits expected (measurable/quantifiable whenever possible);

(b) The timescale within which the benefits are expected to be realized (and when the benefits should be measured);

(c) Any range of acceptability of a particular benefit (e.g., “we are looking for a return of between 18% and 22% on our investment”);

(d) How the project will plan and help assess whether benefits have been realized (this should be documented in a separate “Benefits Review Plan”).

Expected benefits should be tied to organizational strategy.

The Benefits are ultimately what the organization wants to happen from the sponsor and the deliverables and how these will be used and create value for the organization. These can increase, decrease or change due to either internal or external environment changes that either limits or enhances the project.

Timescale

Figure 2: Business Case Development Path

As mentioned in the previously In 'What is a Business Case' the timescale for the Business Case stretches throughout the whole project. The timescale is one of the three basic factors from the Triple Constraint and is needed for every project. As Seen in Figure 2 the timescale can be split into two main sections:

• Developing the Business Case
• Maintaining the Business Case

The two main sections can be split into further points as shown in Figure 1. Under Developing the Business Case there are two important points:

• Verify the Outline of the Business Case
• Verify the Detailed Business Case

Under Maintaining the Business Case there are multiple important points:

• Throughout the individual Milestones the Business Case is verified.
• Whilst the Business Case is being maintained under each milestones the benefits are also confimed
• At Final delivery and post project the Benefits are confirmed.

Example Schedule

Milestones/Deliverables	Target Date
Milestone 1	DD/MM/YYYY
Milestone 2	DD/MM/YYYY
Milestone 3	DD/MM/YYYY
Milestone 4	DD/MM/YYYY
Milestone 5	DD/MM/YYYY

The Business Case should contain a general schedule with the major milestones included with deadlines, as the project progresses the schedule is revised to greater detail.

Cost

According to Murray: The Business Case should summarise the costs derived from the project plan together with the assumptions upon which they are based. The cost should also include details of the ongoing operations and maintenance costs and their funding arrangements. Within the topic of cost, it will be suitable to include a high-level budget, stating but not limited to; Capital investment required, Cost of the salary for the staff working on the project, other relevant costs such as server fees used in the example video from procurement academy.

Major Risks

As part of a successful Business Case the risks needs to be identified. All opportunities are offset by a certain element of risk. A summary should be included of the aggregated risks and highlight the major risks that will have an impact on the business objectives and benefits. When working with determining the risks for a business case, the four steps in the Risk Management process is relevant.

• Identify
• Access
• Control
• Monitor

A relevant tool to apply is the risk matrix where the goal is to minimize the impact or reduce the likelihood of the risk occurring. The person responsible would be the project manager.

Responsibilities

An important aspect of the Business Case is defining the roles of responsibilities and who is responsible for what. According to Murray, there are seven roles relevant to the Business Case.

• Corporate or Programme management
• Executive
• Senior User
• Senior Supplier
• Project Manager
• Project Assurance
• Project Support

Where the project manager is the person responsible of conducting the analysis using relevant tools and updating the Business Case if required.

Relevant Tools

Evaluating and analyzing a Business Case is important to understand and determine whether or not to undertake the project. There are more tools that can be applied however this article will focus on three commonly used tools such as Cost/benefit analysis, Payback Period and Net Present Value(NPV).

Cost/Benefit Analysis

As part of a Business case, the cost/benefit analysis is typically used to quantify whether or not to move forward with the project. The purpose is simply to illustrate and compare the cost with the expected revenue.

Payback Period

The Payback Period is a very simple tool in terms of financial evaluation. The payback period simply compares the revenue generated each year compared with the initial project investment in order to calculate when the money spent on the project is earned back in terms of profit. For example, if the ROI generated is $4 million per year and the initial investment was $20 million their payback period is therefore 5 years. According to Maylor the payback period tools despite its simplicity two limitations:

• the total lifecycle cost of an item and only considers costs within the payback period (if there are major items outside this period to be considered, e.g. high disposal or decommissioning costs, the analysis does not provide a good financial model of reality);
• the time value of money.

Net Present Value (NPV)

The tool Net Present value works as an indication when compiling the Business Case whether the project is feasible or not. The Net Present value is the sum of the present value of the benefits - the present value of the costs. The main criterion is when the NPV is equal or greater than zero, the project will make the company or organization gain value undertaking the project in question.

According to Wikipedia, there are multiple pitfalls for NPV but the first two are listed below.

• If, for example, the Rt(NPV) is generally negative late in the project (e.g., an industrial or mining project might have clean-up and restoration costs), then at that stage the company owes money, so a high discount rate is not cautious but too optimistic. Some people see this as a problem with NPV. A way to avoid this problem is to include explicit provision for financing any losses after the initial investment, that is, explicitly calculate the cost of financing such losses.

• Another common pitfall is to adjust for risk by adding a premium to the discount rate. Whilst a bank might charge a higher rate of interest for a risky project, that does not mean that this is a valid approach to adjusting a net present value for risk, although it can be a reasonable approximation in some specific cases. One reason such an approach may not work well can be seen from the following: if some risk is incurred resulting in some losses, then a discount rate in the NPV will reduce the effect of such losses below their true financial cost. A rigorous approach to risk requires identifying and valuing risks explicitly, e.g., by actuarial or Monte Carlo techniques, and explicitly calculating the cost of financing any losses incurred.

Limitations

The limitations of a Business Case comes to proper and thorough definitions of the described sections in the article. The limitations are found in different areas, where it is the Executives responsibility to delegate the tasks to the people within the project team who has the required skills to complete the task. When choosing the tools to analyze the different sections of the Business Case it is crucial the person conducting the analysis is aware of the limitations of each tool and apply them appropriately. The main limitations of the Business Case lie within the people in the project team. In order for the Business Case to be utilized to its greatest potential, the people within the Project team has to use it as the main guidance document throughout the project and adjust it when required.

References Credibility

In general, using web sources a critical mindset must be used when citing these. Anyone can make a website or create a youtube video, therefore, the web-based sources were kept to a minimum.

The video referenced was made by Procurement Academy. This is a company who deal with competencies training of staff and creates their own content for the training. It was therefore deemed trustworthy by the author and to be used as a source for the article.

'Herman, B. & Siegelaub, J. M. (2009). Is this really worth the effort? The need for a business case.' was used multiple times in the article as a source. The article was published in 2009 on the website for the Project Management Institute, furthermore, the article uses standard reference material.

NPV Wikipedia page was reviewed and deemed trustworthy by the author when looking at the references, and use of both web-based and books as reference material.

Finally, other APPPM articles from the conceptbox were used as references, these are deemed trustworthy sources for information and further reading in addition to the standard material, with the knowledge that the authors behind the articles have done thorough and critical research in relation to the subject.

Annotated Bibliography

• Murray, Andy & Co. (2009), Managing successful projects with PRINCE2, 5th edition, p. 21-28, United Kingdom, TSO.
• Maylor, H. (2010). Project Management, Pearson Education ltd, 4th edition, p.184-191, GB, ISBN: 9780273704324
• Herman, B. & Siegelaub, J. M. (2009). Is this really worth the effort? The need for a business case. Paper presented at PMI® Global Congress 2009—North America, Orlando, FL. Newtown Square, PA: Project Management Institute.
• http://www.projectmanagementdocs.com/project-initiation-templates/business-case.html#axzz4XoPzbU80

Further Reading

Further reading about the template for making a Business case: http://www.projectmanagementdocs.com/project-initiation-templates/business-case.html#axzz4XoPzbU80

Murray, Andy & Co. (2009), Managing successful projects with PRINCE2, 5th edition, p. 21-28, United Kingdom, TSO.

Annotation: The book has a seven-page chapter about Business Case, and describes in details how to develop it.

Maylor, H. (2010). Project Management, Pearson Education ltd, 4th edition, p.184-191, GB, ISBN: 9780273704324

Annotation: The development of a Business Case is explained in seven pages with different examples and descriptions.

Herman, B. & Siegelaub, J. M. (2009). Is this really worth the effort? The need for a business case. Paper presented at PMI® Global Congress 2009—North America, Orlando, FL. Newtown Square, PA: Project Management Institute.

Annotation: Article published by the Project Management Institute in 2009, explaining the essentials of a Business Case and its importance.

H. Pearson, "Project Management", Chapter 10 Pearson Education Limited, 4th. Edition (2010)

Annotation: This chapter is about Risk & Opportunities Management and describes: risk matrix, Rumsfeld's Known-unknowns, qualitative and quantitative approaches, sensitivity analysis, PERT technique and Monte Carlo simulation.

Beyond the Triple Constraint

Annotation: Article from the conceptbox describing the further definition of the iron triangle, and its relevance creating guidelines for project managers.

Risk Management Overview

Annotation: Article from the conceptbox describing an overview of Risk Management, relevant to the Business Case when working on the risks associated.

Risk management

Annotation: Further reading from the conceptbox describing Risk analysis and Risk Management in practice.