Purpose of a Business Case click here for more details
The Business Case has a number of objectives:
■ Project validation; to carry out an internal check to
ensure that the project is worth doing, i.e. the benefits
outweigh the costs.
■ Responding to events; if something changes during the project, the Business Case enables repetition of
the internal check.
■ Internal communications; to ensure that all of the stakeholders are aware of the benefits.
The Business Case is the key document within the Project Management Plan (PMP). At any time during the project we can refer to the Business Case to see whether the project is still justified, and to check that the relevant elements of the business environment have not changed significantly.
The ultimate success of a project is measured by the realisation of the benefits, so the benefits as described in the Business Case drive the project. All decisions about the project should be made by considering the expected benefits.
It is important to note that a Business Case is written to justify the amount to be invested in the project, so it is written from the perspective of the customer (who is funding the project), rather than the supplier (who is supplying work to the project). In other words, the Business Case says, “What return can we expect on our investment?” or “How much is it going to cost us to achieve these benefits
for our business?”
Who is involved?
The Project Sponsor owns the Business Case and therefore will usually produce it. However, it is possible that the Project Sponsor will oversee the development of the Business Case by the Project Manager. In many environments the Project Manager does all of the ‘leg work’ and the Project Sponsor
directs and approves the Project Manager’s work. But even if the Project Sponsor delegates this work to the Project Manager, the Project Sponsor still owns the project and therefore owns the Business Case as well.
For more details on the responsibilities of each role in the project, see Chapter 4: Project Organisation.
click here for more details
Business Case contents
Different organisations will write Business Cases in different ways. But these are the items that should always be included as a minimum:
Reasons: These are the reasons why we are considering carrying out the project. This tends to be a description of the current situation. For example, if the proposed project is to move house, the reason might be that we are not happy with the current area in which we live. If the suggested
project is to produce a new computer system, the reasons for the project might include the fact that the old system is costing the organisation too much to maintain.
Options: These are the options that have been considered, which may solve the current problem or situation. There may only be one option, but normally there will be a few. Including ‘Options’ as an item ensures that all options are considered. One of the options that should always be considered is ‘do nothing’; sometimes organisations can get carried away with the thought of a bright, shiny new
product, whereas actually the most cost-effective option
may be to stick with what they already have.
“The best way to have a good idea is to have lots of ideas.”
Linus Pauling
(American theoretical physical chemist)
Benefits: these are the positive outcomes that the project is expected to bring into the organisation. In commercial environments, benefits are usually financial, such as increased revenue or cost savings. Even benefits that at first sight seem to be non-financial can often be translated into financial ones. For example ‘improved staff morale’ will translate into ‘reduced staff turnover’ and then into
‘reduction in recruitment and training costs’.
Benefits are best stated in measurable terms. If the benefits are financial, this is fairly easily done. If they are intangible, for instance ‘improved educational facilities’, then some form of measurement needs to be contrived, if at all possible. You could measure ‘improved educational facilities’ by surveying a large number of people and specifying a target of 80% of those questioned agreeing
that the educational facilities have been improved. Quantification of intangible factors is often hard to do and controversial; there are inevitably many different opinions as to the true value of something that is hard to measure.
Most projects will have a mixture of tangible (usually financial) benefits and intangible benefits.
Sometimes the benefits of carrying out a project relate more to the reasons that we cannot avoid doing it. For instance, if we do not update the accounting system to take account of the new VAT rules, we will be in violation of the law.
Cost and time: these are simple notes of the estimated cost and time of the project, so that the benefits can be compared against the cost, and the time taken to develop the project can be taken into account against the benefits. If there is a cost impact on the rest of the customer organisation, then this should be included.
Risks: these are the major risks against achieving the benefits. Detailing them enables the risks to be compared against the benefits. It may be that our assessment of the risks of the project means that the risks outweigh the potential benefits, so we may not continue with the project. It is often the case that a high benefit project is high risk, and equally a low risk project often achieves relatively low benefits (compare the race to put a man on the moon versus putting up some shelves in your study).
click here for more details
Cost-Benefit Analysis: this is the mathematical comparison of the negative costs against the positive benefits.
This is relevant where the benefits of a project are financial and so can be compared against the costs. There are a few methods of undertaking this, but the simplest is the Payback method.
The Payback method lists the costs in each year, the financial benefits in each year, then calculates
the cash flow for each year and works out the cumulative cash flow through the next five years of operation.
For example, an IT project to replace a legacy system has a development cost of £100K and an operational cost of £20K each year after that. The legacy system was expensive to maintain and savings of £50K per year will be made once the new system is in place.
Cash flow is the simple subtraction of costs from benefits, in each year. (So in year 1, cash flow is 50 – 20 = 30.)
Cumulative cash flow is the sum of the cash flow figures totalled up as you go, so that you can see the position after each year, similar to the balance in a bank account. So cumulative cash flow in year 1 is calculated by taking the cumulative cash flow in year 0 and adding the cash flow in
year 1, i.e. (100) + 30 = (70).
This calculation shows that Payback, that is when we will break even, occurs in year 3, as this is when the cumulative cash flow figures become positive, i.e. the project is ‘in the
black’ in its bank account.
This is a very simple method of cost-benefit analysis. There are other methods which involve taking into account the decreasing value of money over time.
click here for more details
