Business Case
(→References) |
(→Net Present Value (NPV)) |
||
Line 157: | Line 157: | ||
If, for example, the Rt are 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. | If, for example, the Rt are 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. | + | 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.<ref name="NPV"/> |
=Limitations= | =Limitations= |
Revision as of 17:59, 26 February 2018
Contents |
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)[2] 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) [3] ‘. . . 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.’
What is a Business Case
A Business Case is the reference point before, during, and after a project the organisation 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 organisation 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?”[4]
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. [4]
Defining a Business Case
When defining a Business Case the aim is to address all of the six areas shown in Figure 2. The six-star constraint is an expansion of the classical triple constraint.[5]
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. [6]
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 organisation 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.
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 conceptualising 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 organisation. [2] [4]
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.[4]
The Benefits are ultimately what the organisation wants to happen from the sponsor and the deliverables and how these will be used and create value for the organisation. These can increase, decrease or change due to either internal or external environment changes that either limits or enhances the project.
Timescale
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 1 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. [6]
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. [6]
Cost
Major Risks
As part of a successful Business Case the risks needs to be identified.[7]
Responsibilities
Sponsor Role
Relevant Tools
Evaluating and analysing 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). [1][6]
Cost/Benefit Analysis
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 revenue generated is $4 million per year and the initial investment was $20 million there 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 (see below). [3]
Net Present Value (NPV)
If, for example, the Rt are 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.[8]
Limitations
The limitations of a Business Case comes to proper and thorough definitions of the described sections in the article.
References
- ↑ 1.0 1.1 https://youtu.be/bDAsAbMMep0, Procurement Academy 2015, Business Case - Definitions
- ↑ 2.0 2.1 2.2 Murray, Andy & Co. (2009), Managing successful projects with PRINCE2, 5th edition, p. 21-28, United Kingdom, TSO.
- ↑ 3.0 3.1 3.2 Maylor, H. (2010). Project Management, Pearson Education ltd, 4th edition, p.184, GB, ISBN: 9780273704324
- ↑ 4.0 4.1 4.2 4.3 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.
- ↑ 5.0 5.1 Beyond the Triple Constraint, Concept Box, Beyond Triple Contraint, APPPM
- ↑ 6.0 6.1 6.2 6.3 http://www.projectmanagementdocs.com/project-initiation-templates/business-case.html#axzz4XoPzbU80, template of Business Case, supplied by Project Management Docs
- ↑ Risk Management Overview, Concept Box, Beyond Triple Contraint, APPPM
- ↑ https://en.wikipedia.org/wiki/Net_present_value, Net Present value, Wikipedia
References Credibility
In general, using web sources a critical mindset must be used when citing these. 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.
Annotated Bibliography
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 explaned 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.
Annotation:
Annotation:
Annotation: