Business Case
< Project Name > ProjectTemplates®
Document Control
Changes History
Issue Number / Date / Author / Change /Authorised by
Role / Name / Signed / DateDistribution
Name / Organisation[Guidance is enclosed in square brackets ([ ... ]) and should be deleted from the final document. Items enclosed in chevrons (< ... >) are placeholders and should be replaced (including the chevrons) by appropriate text. Any text outside square brackets or chevrons is standard text that should be included in the final document.
Use the standard heading styles (Heading 1, Heading 2, Heading 3) to create any new headings. If you add or delete any headings, the numbered bullets will be automatically adjusted. Do not use more than three levels of headings.
Create a new table of contents by selecting the current table of contents, selecting Insert | Index and Tables…, and clicking OK in the Table of Contents Tab.]
Contents
1 Executive Summary 6
2 Purpose of Document 6
3 Reasons for Undertaking the Project 6
3.1 Business Need 6
3.2 Consequences of Not Undertaking the Project 6
3.3 Strategic Fit 7
3.4 Fit with Programme Plan 7
4 Options 7
4.1 Options Considered 7
4.2 Options Appraisal 7
4.3 Selected Option 7
5 Benefits 8
5.1 Benefits Expected 8
5.2 Benefits Realisation 9
6 Resources and Costs 9
7 Budget SOURCE 11
8 Investment Appraisal 12
9 Timescales 12
10 Key Risks 12
GENERAL GUIDANCE
Purpose
The purpose of the business case is:
· to obtain management commitment and approval for investment in business change, through a clearly presented rationale for the investment;
· to provide a framework for informed decision making in planning and management of the business change and subsequent benefits realisation.
It seeks to establish that the proposed project will;
· meet the business need;
· take forward the most appropriate option;
· achievable;
· be affordable;
· offer value for money.
It should be recognised that a business case is a powerful decision making tool, both in deciding if a project should be undertaken, but also if it should continue during the duration of the project. It is therefore essential that it is maintained throughout the project and reviewed at each key decision stage, to check that it is still valid and achievable.
Development of the Business Case
The business case is a working document. It will begin to be developed during the pre-project stage (preliminary business case), where it is documented within the project charter. It is extended during the feasibility/start-up stage (outline business case) and should be baselined during the project initiation stage (full business case). There are no hard and fast rules as to the level of detail required at each stage, but some broad guidance is provided below:
Preliminary Business Case (Pre-Project Stage)
High level view, confirming the strategic fit and business need, the types of benefits that will be delivered and the consequences of not undertaking the project. This will normally be presented as part of the project charter.
Outline Business Case (Feasibility/Start-up Stage)
Quantification of benefits should begin to emerge, along with costs.
Full Business Case (Initiation Stage)
Benefits fully quantified and benefits realisation plan documented. Detailed breakdown of resources and costs should be included.
[The level of detail required very much depends upon factors such as overall cost, complexity and risk.]
[For small projects, it may be possible to produce the business case in one stage, with confirmation of prices, funding availability etc.]
[Any exceptions to this should be agreed beforehand with the PMO.]
[To support the guidance included in this template, a model business case is available.]
[In addition there is a wealth of guidance on developing the business case on the OGC web site at:
Executive Summary
[This section should be used to provide relevant background information about the project and briefly summarise in simple terms the aims of the project, the benefits of undertaking the project and the consequences of not undertaking the project. Typically this is best presented as a series of bullet points, under the headings ‘Project Aims’, ‘Benefits’, ‘Consequences of Not Undertaking the Project.]
Purpose of Document
[This section should include a standard statement describing the purpose of the Business Case. An example is given below.]
The purpose of the Business Case is to document the justification for the undertaking of the project based on the estimated cost of development and implementation against the risks and the anticipated business benefits and savings to be gained. The total business change must be considered, which may be much wider than just the project development cost.
The Business Case is used to say why the forecast effort and time will be worth the expenditure. The Project Board will monitor the ongoing viability of the project against the Business Case.
Accountability for the delivery of benefits outlined within the business case is the responsibility of the project executive. In most cases the benefits will be delivered and measured after the completion and closure of the project.
Reasons for Undertaking the Project
Business Need
[Explains why the project aims are required, including a description of the business need and why it is needed now. Often this is best presented as a series of bullet points].
Consequences of Not Undertaking the Project
[The consequences of not undertaking the project should be presented as a series of bullet points].
Strategic Fit
[Describes how the project contributes to Government Initiatives, the Company’s Strategic Objectives, the Programme Vision. Explains the compelling case for change, in terms of the existing and future operational needs of the company. Also explains how the project fits with the Modernising Government Agenda for electronic commerce (access to online services, use of web-enabled technology and compliance with associated interconnection standards).]
Fit with Programme Plan
[Affirms the project’s place in the programme, and confirms which programme-sub committee will adopt it.]
Options
Options Considered
[An outline description of the different options considered to deliver the project’s outcome. Where a large number of options are identified, it may be advisable to carry out a brief short-listing exercise. A ‘do-nothing’ option must always be included.]
Options Appraisal
[High level appraisal of the various options covering areas such as cost, benefit, quality, time, risks and opportunities.]
Selected Option
[Identify the selected option, giving the reasons for its selection]
Benefits
Benefits Expected
[Any benefit identified within the business case must be capable of being measured. If it is not possible to derive a method of measuring the benefit, it should not be used as a justification for the business case.]
[This section should identify the benefits expected to be achieved by the project’s outcome. Each benefit should be expressed clearly in measurable terms against today’s situation, detailing any assumptions made in quantifying the benefit, and the timescale for delivery of the benefit. Typically high level benefits are presented as a series of bullet points and then expanded to provide quantification of the benefits in tabular form, as below.]
Measurable Benefit / Assumptions / Timescalea. / Quantified benefit, usually (but not always) in monetary terms (saving or cost avoidance). / What assumptions have been made in quantifying the benefit? What are the baselines against which benefits can be measured? / When is it expected that the benefit will be delivered?
b.
c.
etc
[In addition to benefits, a project may also have dis-benefits. Dis-benefits have the same properties as a benefit but have a negative impact upon the business. It is important that dis-benefits are identified, measured and tracked, but the focus will be on minimising the negative impact that a dis-benefit will have, whereas the effect of a benefit needs to be maximised.]
MeasurableDis-Benefit / Assumptions / Timescale
a. / Quantified dis-benefit, usually (but not always) in monetary terms (increased cost or new cost). / What assumptions have been made in quantifying the dis-benefit? What are the baselines against which dis-benefits can be measured? / When is it expected that the impact of the dis-benefit will be felt?
b.
c.
etc
Benefits Realisation
[Identify how the achievement of each claimed benefit (and dis-benefit) will be measured, and the timescale for doing so. Every benefit (and dis-benefit) included in section 5.1 must have a benefits realisation entry in section 5.2. Where appropriate, this should fit with the Programme Benefits Management Strategy.]
Benefit Measurement Technique / Timescale for Measurement of Benefita. / How will the benefit quantified in 5.1 be measured? / When will the benefit be measured? This is likely to be over a period of time, perhaps quarterly or annually.
b.
c.
etc
Dis-Benefit Measurement Technique / Timescale for Measurement of Benefit
a. / How will the dis-benefit quantified in 5.1 be measured? / When will the benefit be measured? This is likely to be over a period of time, perhaps quarterly or annually.
b.
c.
etc
Resources and Costs
[Estimate the resources and capabilities (people, physical resources and funding) that will be needed.
These budgetary estimates should be for the whole life of the development, not just the direct project costs.
Include the costs that will be carried by the company as well as those that will be charged by suppliers. It will be necessary to make certain assumptions when estimating these costs, and these assumptions should be detailed in the appropriate column.
Note that savings or benefits achieved in one part of the organisation may add to costs elsewhere in the organisation or delivery chain.
Include a risk allowance needed to cover the cost of the risks most likely to materialise.]
External Costs
Project (including VAT) / Ongoing (per year) including VAT)Supplier 1 / £ / £
Supplier 2 / £ / £
Hardware / £ / £
Software / £ / £
Contingency / £ / £
etc / £ / £
Total / £ / £
External Costs – Ongoing (per year)
Project (including VAT) / Ongoing (per year) including VAT)Support Costs / £ / £
Maintenance Costs / £ / £
Licensing Costs / £ / £
etc / £ / £
Total / £ / £
[Unless alternative arrangements have been agreed, new applications to be incorporated within the supplier in-service support arrangements should be costed as follows:
Small Application (£21K - £100K); £10K per year for application lifetime
Medium Application (£101K - £500K) £50K per year for application lifetime
Large Application (>£500K) £100K per year for application lifetime.
For enhancements to existing applications, existing support arrangements may be acceptable moving forward, with no increase necessary. This should be discussed with the Xansa in-service support manager and the outcome recorded in the business case.
In all instances, support costs should be monitored against the business case at pre-defined intervals.]
Internal Costs - Project
Activity / Assumptions / Effort (days) / Estimated Cost (including VAT)Attendance at meetings (requirements gathering, checkpoint, board etc) / £
User acceptance testing / £
Development of training materials / £
Contingency / £
etc / £
Total / £
Internal Costs – Ongoing (per year)
Activity / Assumptions / Effort (days) / Estimated Cost (including VAT)Ongoing support activities / £
Support of enhancements / £
etc / £
Total / £
Budget SOURCE
[The budget source for the project should be confirmed. If there are multiple budget sources, these should be listed, with the amount/proportion of budget to be set against each budget source. Typical budget sources are:
• Programme Admin Budget;
• Departmental Budget.
The status of the budget should also be clarified. Is the budget secured, subject to a current bid, at proposal stage etc? This information may be presented as a table, and if so, the table below may be used:
Budget Source / Name of Budget Holder / Amount/Proportion / StatusBudget source 1
Budget source 2 etc
Investment Appraisal
[The investment appraisal illustrates the balance between the development, operational, maintenance and support costs against the financial value of the benefits over a period of time. This period may be a fixed number of years or the useful life of the product.
A sample spreadsheet is included here and this may be adapted for the needs of the specific project. The sample spreadsheet includes standard cost and benefit elements spread over five years (the assumed life of the system) with values discounted at a rate of 3.5% per annum.
The spreadsheet includes a net present value calculation which demonstrates the viability (or otherwise) of the project. In general terms, the project may be regarded as viable of it shows a positive overall return on the investment (the net present value).
In addition to the cost elements shown in the spreadsheet, it may be necessary to consider items such as software maintenance/support, software evaluations, telecommunications, procurement costs, gateway reviews, cabling costs, etc.
Further guidance on completing the spreadsheet can be provided by the programme management Office (PMO)]
Timescales
[Estimate timescales for the delivery of the project’s outcome]
Key Risks
[Summary of the key risks of the project (usually top 5 risks)]
© ProjectTemplates® – Project Templates 2 | Page