The Business Case is the corner stone of any project under PRINCE2®. It must be viable before a project will be approved by the Project Board. It does not just exist at the start of a project but features all the way through. If at any point the Business Case fails the project must be stopped.
The Business Case should be considered in a broad sense. If you are purchasing a piece of equipment it is not just the cost of this but its impact on many other areas, for example:
The Business Case is influenced by the following elements:
The Business Case must contain enough information so that the Project Board can make the necessary decisions. It will be supported by other documentation. The full Product Description appears in the templates file with the full package as 'business case.doc'.
This is the rationale for the existence of the project. Why is it needed? This information should be contained in the Project Mandate. If this is not the case more work is required at the 'Starting up a Project' stage.
The Project Board requires assurance that more than one option was considered for the project outcome. These should be described and the primary one put forward for use in reaching the project outcome. There report should contain the reasons for the choice.
Each benefit must be indicated that would arise from the completion of the project. Each of these must be measurable so that progress can be monitored. The information should indicate how the measurement would be attained. Compare these with SMART targets.
In order to see a benefit there has to change. Hence, any benefit must be measures against the current status.
The Executive will define the benefits.
It may not always be easy to define the benefits in a 'positive' manner in absolute terms. Sometimes it is easier To begin discussion with a 'negative' approach. For example:
'If we do not carry out this project we would lose out in the following areas', for example:
Summarises the key risks to the project that may affect the outcome. The Risk Log will contain details of how they will be managed. Note that there will be many potential risks that could have a very serious outcome to the project. However, these need to be considered in the light of the possible occurrence. The impact may be high but the probability of it occurring may be extremely low.
These aspects are discussed in much more detail in the 'The Complete Risk Management package'.
This information is contained in the Project Plan. If an accurate assessment is not ready you will need to provide a good estimate that would be refined later.
This is where the company must assess the potential profit from the project over a number of years. Either a fixed number of years must be chosen or the assessment would be done over the useful life of the product. This will weigh up the income generated against the costs incurred. Those costs would be:
This situation is compared against the 'not doing the project'.
It is important to try to indicate benefits in a measurable way. This is often easy for 'tangible' benefits, for example, improved efficiency means less defects and reduced rework costs. However, intangible costs, usually expressed emotionally, can be harder to define. For example:
This can be translated as less days sick, less staff turnover, increased performance. All of these can be measured and converted to cost savings.
Evaluation of the claimed benefits is important. If, for example, the increased benefits equally contribute to the overall Business Case there will be reduced risk of failure if one of them fails to materialise. If, however, the Business Case depends heavily on one benefit there must be focus here to support and protect it against failure. In this case 'sensitivity analysis' may prove useful.
This stands for 'Good, Average, Poor'. Just stating one level of benefit can be a risk and may not be very realistic. By putting forward 3 options you will gain a more realistic feel of the possible benefits.
So these refer to:
Good: what you are expecting (hope) to happen Average: what may happen if things go well Poor: the worst case scenario.
The latter case will have increased costs associated with it that will offset the risk of lower performance. Depending on the view of the Project Board the decision making process may be straight forward or complicated by uncertainty.