Project Business Case template

(Medium to Large Projects)
Template and Guide
Version 2.1, April 2008
This guide is intended to be read in conjunction with the following template for the development of a Project Business Case. As such, the Guide should be removed from the front of your final document.
Another template for the development of a Project Business Case for a smaller, less complex project (Small Project Business Case) has also been developed. This is available at
License URL:
Please give attribution to: © State of Tasmania (Department of Premier and Cabinet) 2017
What is a Project Business Case?
The Project Business Case is a one-off, start-up document used by senior management to assess the justification of a proposed project, as the basis for comparison of a number of projects competing for limited funds, or to assess the options for a project that has already received funding. If approved, it confirms senior management support and/or resourcing for a recommended course of action (option). .
Why would you develop a Project Business Case?
A Project Business Case is developed to:
• gain approval to proceed with one or more projects;
• obtain resourcing for a project or projects through internal departmental processes, or the Budget Committee process; or
• where resourcing is already available, to document what the project can accomplish for the funding and how, e.g. a project as a result of a ministerial direction.
The document enables those approving the resources to analyse the rationale for the project, assess the economics of the project (both financial and strategic), analyse the impact of the project and compare these against other factors, such as the major risks and the prevailing political environment.
Where an Agency, Division or Business Unit has a number of project initiatives, the Project Business Case can be used as a tool to prioritise the various initiatives.
When would you develop a Project Business Case?
Approval to develop a Project Business Case is usually obtained from the acceptance or approval of a preceding stage, such as a Corporate Plan for a Department, Business Plan for a Business Unit, Strategic Information Systems Plan, Project Proposal, Business Process Review Report or Feasibility Study The Project Business Case expands the proposals developed in these documents, in order to:
• obtain approval for resourcing for a preferred option;
• obtain agreement on a realistic scope where resources have already been approved; and
• gain authorisation to proceed to the next step of the project , which is usually the development of the Project Business Plan.
Alternately, direction may be given by the proposer of a project to proceed directly to the development of a Project Business Plan without development of a Project Business Case. This causes problems if the scope has not been agreed, or if there has been no assessment as to whether the resources are sufficient for the scope.
What you need before you start:
• Agreement to proceed with the development of the Project Business Case from the Project Sponsor or Proposer.
• Project outline or scope document establishing the proposed scope of the Project Business Case.
• Knowledge and understanding of the development of a Project Business Case, as outlined in the Tasmanian Government Project Management Guidelines.
Also advisable:
• Any of the following documents – Strategic Information Systems Plan, Project Proposal, Process Review Report or Feasibility Study.
• Knowledge and understanding of performing an economic assessment on the option(s), for example by preparing a Cost-Benefit Analysis.
• Ministerial statement, press release.
• Treasury guidelines for Business Cases.
• Corporate/Business Plan for the Department/Business Unit.
• Departmental Project Initiation Guidelines.
What you will have when you are finished:
A completed Project Business Case that is ready for acceptance by the Project Sponsor or Project Steering Committee through internal departmental processes or the Budget Committee process.
Integration Process
This document is a one-off start-up document. It will not be updated and/or revised as the project progresses.
Relevant sections of the Project Business Case may be integrated into any subsequent project management documentation should the project proceed.
How to use this template:
The template contains sections which are either optional or can be developed at a number of levels of detail depending upon individual need.
All documents developed based on this template should include an appropriate acknowledgement.
A number of different text styles have been used within the template, as follows:
• Text in blue italics is intended to provide a guide as to the kind of information that can be included in a section and to what types of projects it might be applicable. It should be deleted from the final document .
• Text in normal font is intended as examples.
• Text enclosed in is intended to be replaced by whatever it is describing.
• This document has been formatted for duplex printing. If you intend to print single sided, you may need to delete some page breaks.
Where to Get Additional Help
Project Management tools and resources that can assist you through each step in your project are available at
Have you remembered to remove:
• The versioning statement from the front cover of your document?
• This guide and checklist from the front of your document?
• All blue italic instructional text and within the template? Project Business Case
Version: Date: Copy: Uncontrolled
The version number starts at one and increases by one for each release. It shows the release number and a revision letter if in draft. The original draft is 0.A and subsequent drafts are 0.B, 0.C etc. The first accepted and issued document is 1.0. Subsequent changes in draft form are 1.0A, 1.0B etc.. The accepted and issued second version is 1.1 or 2.0, depending on the magnitude of the change.
Refer to the Project Management Fact Sheet: Document Control, for more information at
Document Acceptance and Release Notice
This document is Version date: of the Project Business Plan.
The Project Business case is a managed document. For identification of amendments each page contains a release number and a page number. Changes will only be issued as complete replacement. Recipients should remove superseded versions from circulation. This document is authorised for release once all signatures have been obtained.
PREPARED: Date: – –
(for acceptance) Name, Title ACCEPTED: Date: – –
(for release) Name, Title Project Sponsor
Document Development History
Build Status:
Version Date Author Reason Sections

List the most recent amendment first Initial Release All
Amendments in this Release:
Section Title Section Number Amendment Summary
eg.This is the first release of this document.
Copy No Version Issue Date Issued To
Electronic Shared drive
Table of Contents
1 Executive Summary 11
2 Introduction/Background 12
3 Overview 13
3.1 Project Title 13
3.2 Vision 13
3.3 Organisational Objective 13
3.3.1 Government Objective(s): Tasmania Together 13
3.3.2 Australian Government Objective(s) 13
3.3.3 Corporate Objective(s) 13
4 The Business Case 14
4.1 Purpose of the Business Case 14
4.2 Sponsor 14
4.3 Intended Audience 14
5 Situational Assessment and Problem Statement 15
6 Critical Assumptions and Constraints 16
7 Analysis of Options 17
7.1 Identification of Options 17
7.2 Comparison of Options 17
7.3 Recommended Option 18
8 Benefit/Cost/Risk Analysis 19
8.1 Benefits & Disbenefit s 19
8.2 Costs 19
8.3 Stakeholder Analysis 20
8.4 Key Issues 20
8.5 Identified Risks & Minimisation Costs 20
8.6 Summary of Benefit/Cost/Risk Analysis 20
9 Implementation Strategy 21
9.1 Target Outcomes 21
9.2 Outputs 21
9.3 Stakeholders 21
9.4 Related Projects 21
9.5 Organisational Impact 21
9.6 Outcome Realisation 22
9.7 Work Plan 22
9.8 Resources 22
9.9 Project Management Framework 22
10 Glossary and Appendices 23
Appendix A: Benefit Analysis 25
A.1 Summary of Options 26
Appendix B: Risk Analysis 27
1 Executive Summary
The Executive Summary is the part of the document that most people will read first, if not the only part. As such, it should summarise the document, be able to stand alone as a logical, clear concise summary of the document and highlight the key issues that the reader should be aware.
It should report on the results of the analysis rather than the reasoning behind them.
Types of things on which to focus:
• the definition of the business needs;
• relationship to the Strategic/Corporate Plan;
• relationship to Tasmania Together benchmarks (where appropriate);
• summary of options;
• costs;
• benefits; and
• key recommendations.
There is no need to include:
• assumptions and constraints (unless they are key);
• background (except for perhaps one sentence);
• analysis;
• reasoning; and
• details of any form.
For ease of reading consider organising the information into bulleted or numbered points.
This should be developed after the rest of the document has been completed.
2 Introduction/Background
This is used to introduce the business problem, briefly describe what has happened in the past to address the problem, and what is the current status at the time of writing the Project Business Case. What is the rationale or the reason for developing the Project Business Case at this particular time?
3 Overview
3.1 Project Title 3.2 Vision
What is the goal of the project, what is it expected to deliver? A high level description of the objective(s) of the recommended option contained in this Project Business Case (a one-liner).
3.3 Organisational Objective
All projects should relate to and produce results that relate to a pre-defined organisational goal(s). The Objectives Hierarchy directly links a project’s activities with the organisational goals and direction of the Agency, providing the context in which the project is being undertaken. Where a project is contributing to the implementation of national policy decisions, it may also be necessary to include references to relevant Australian Government policy objectives in this section.
3.3.1 Government Objective(s): Tasmania Together
Include relevant Tasmania Together Benchmarks and Goals here.
3.3.2 Australian Government Objective(s)
Include relevant Australian Government policy objectives here.
3.3.3 Corporate Objective(s)
Include relevant Departmental and/or Divisional Goals here.
4 The Business Case
4.1 Purpose of the Business Case
Why is the Project Business Case being produced?
Generally it is to:
• define the business need or problem in detail;
• analyse options (where resources have already been allocated this may involve determining what can be delivered with those resources);
• identify costs, benefits and risks; and
• to put forward a proposal to senior management for approval to proceed with the project, or to the funding source for approval for funding for the project.
4.2 Sponsor
Who is sponsoring the development of the Project Business Case?
4.3 Intended Audience
Who is the document intended for? Helps the author in presenting an appropriate picture as well as helping the reader know if the document is aimed at them, e.g. Agency Executive, Budget Committee.
5 Situational Assessment and Problem Statement
This section should clearly establish the benefit to the organisation for proceeding with the proposed project(s). It should contain:
• a description of the relevant environmental conditions;
• an assessment of how the business needs are currently being met, or not met;
• an analysis of the gap between the current situation and the stated objective(s).
6 Critical Assumptions and Constraints
It is essential that assumptions made during the planning process are recognised and recorded.
This may include assumptions arising from previous documents, such as a Project Proposal, a Feasibility Study or other existing strategic business documents. Include a discussion of the implications if the assumption is wrong. This is often a risk to the project.
Any requirements for specialist resources or skills should be identified here, and any dependencies that exist with other projects or initiatives.
Constraints may change, so a discussion of the implications of this should also be included, e.g. the budget that has already been allocated may not be the constraint it initially appears to be.
Do not create any if you cannot identify any.
7 Analysis of Options
This is a high level analysis of the possible alternatives that could be employed to bridge the gap between the current situation and what is proposed, as outlined in Section 5.
The content and structure of this section is very subjective and case-by-case specific. In general, the degree of analysis should reflect the significance of the decision and the expectations and requirements of the decision makers (generally this is related to the magnitude of the investment). If there are a number of significantly different options for proceeding, a feasibility study may have been carried out on one or more of these options that reduces the complexity of the option identification.
7.1 Identification of Options
Generally if a detailed analysis of options is required, then fewer significant options are preferable to many. To ensure that a thorough assessment is made of all possible alternatives, a minimum of 3 options may need to be considered, such as:
• Option 1 – do nothing – maintain the existing situation
• Option 2 – An option that would achieve the same result
• Option 3 – The preferred option
Any minor variations between apparent options should be resolved at this stage based upon the assumptions, constraints, areas of risk (if identified) etc., leading to the ‘best case’ scenarios for each major option. If such an analysis results in only one option appearing viable, then that option should still be analysed – preferably against the current situation to assist in providing a reference point in decision making (even if the current situation has been eliminated as an option).
7.2 Comparison of Options
The benefits, disbenefits, direct and recurrent costs, and the major risks and the cost of risk minimisation should be identified for each option. This should be a summary and may best be displayed in a table. If a detailed analysis is necessary it should be included in the Appendices. For many initiatives the benefits/disbenefits are not directly quantifiable or financial, for example improvements in service delivery or achievement of Government policy objectives. A possible way of assessing these is included in Appendix A. This requires all major stakeholders to be identified. A risk analysis worksheet is in Appendix B.
Criteria Option 1 Option 2 Option 3
• Stakeholder A
• Stakeholder B $ or rating
• Stakeholder A
• Stakeholder B
• Direct
• indirect
• recurrent
• initial
• minimisation/ mitigation costs
• resulting risk
Use dot points to list how each option addresses the assessment criteria.
7.3 Recommended Option
The recommended option from the previous analysis should be identified here.
8 Benefit/Cost/Risk Analysis
This section analyses the recommended option in detail.
If a benefit/cost/risk analysis is appropriate, the benefits, disbenefits, direct and recurrent costs, and the major risks and the cost of risk minimisation should be identified.
Depending upon the scope of the organisation for which the Project Business Case is being prepared, it may not be appropriate for some financially quantifiable benefits or costs to appear as direct in the analysis but rather as indirect financially quantifiable benefits (e.g. Revenues from the public may be a direct financial benefit if collected and retained by the organisation for whom the Project Business Case is being prepared, but they are also an indirect (financially quantifiable) cost to the public if they represent an increase on current charges.).
To justify a recommendation the analysis should incorporate economic and social outcomes to be delivered/received from the proposed initiative. Meeting a customer service obligation is an important non-financial benefit for a service delivery organisation.
8.1 Benefits & Disbenefits
The Benefits and Disbenefits need to listed.
These should include such things as:
• Cost related benefits
 increased revenue;
 cost reductions, e.g. reduced maintenance, reduced staff costs;
 cost avoidance, e.g. increased service with the same staff.
• Service related benefits
 achievement of policy objectives, e.g. better community health, safer workplaces;
 service enhancement, e.g. faster service, greater availability;
 improved productivity.
8.2 Costs
Typical costs include capital and recurrent costs including human resource costs. It is important to include recurrent costs as these will occur after the project has closed and must be budgeted for separately by the organisation.
Most costs can be reduced to a dollar amount and analysed over time. The appropriate time to analyse over will be determined by the expected life of the change initiative and advice should be sought from the business owner on what is considered appropriate.
The following costs should also be included:
• risk management costs; and
• quality management costs.
Generally for a government agency, a Net Present Value (NPV) analysis and a Cash Flow projection will be required for the recommended option.
Sources of funds, if required, may also be identified here.
8.3 Stakeholder Analysis
From Section 7.2, list the major stakeholders and analyse them using the template below.
How could this stakeholder …
Stakeholder Impact the project? Be impacted by the project? Issues raised for this stakeholder How will we engage this stakeholder?
8.4 Key Issues
Identify any key issues and how they will be addressed.
Issue Why the Issue is Important Plan to Deal with the Issue
8.5 Identified Risks & Minimisation Costs
Provide an analysis of the costs associated with the level of risk for the recommended option. This should include risk minimisation and mitigation costs. It should be noted that these costs may never be incurred if the threat is not realised.
8.6 Summary of Benefit/Cost/Risk Analysis
A short statement summarising the overall rating of the project across all three parameters.
9 Implementation Strategy
The information in this section is important, as it will form the basis of a Project Business Plan if the project/initiative proceeds. It defines the scope of the project.
Identify the type of approach to implementing the preferred option, for example one large project, a number of smaller projects or a combination of both. Larger projects can be organised into phases – major sections of work that deliver outputs (but not outcomes). Projects that may take several years to complete should be scoped in stages, with each stage producing outputs for utilisation, allowing some outcomes to be generated.
9.1 Target Outcomes
List of target outcomes, measures, targets and dates for achievement. These should be derived from Section 8.1.
9.2 Outputs
Complete list of deliverables and their critical fitness-for-purpose features.
9.3 Stakeholders
List of those to whom outputs will be delivered and a short description of how each stakeholder will utilise each output to generate target outcomes.
9.4 Related Projects
Related projects (or major change initiatives) can be of significance to the project.
List related projects dependent on/or interdependent with this project; or whether this project is dependent on other projects.
The nature of a dependency can include a shared relationship with data, functionality, staff, technology and/or funding.
9.5 Organisational Impact
How will the work undertaken during the project impact on the organisation and how will these impacts be addressed.
9.6 Outcome Realisation
Outcome Realisation refers to the management of the utilisation of outputs to meet the target outcomes, and bring about longer term benefits. Outline how outputs will be managed once they are delivered, and who will be accountable. This may change throughout as the project evolves, and will be detailed in a standalone Outcome Realisation Plan (see template and guide at ).
9.7 Work Plan
Outline of project phases, major areas of work and key milestones.
9.8 Resources
Budget and list of critical human/information resources – noting when those resources are required for the project. Include such things as:
• Budget
• Human resources
• Information
• Infrastructure required
9.9 Project Management Framework
This describes how the project will be managed. It is an outline only; the detail should be contained in the Project Business Plan.
Outline the proposed:
• Project governance model (who is responsible for what)
• Quality Plan – consists of quality assurance (the standards and methodology) and quality control (a checklist of things to verify that the outputs have been delivered) e.g. the meeting schedule, project monitoring arrangements, structure/format of reports
• Plan for Organisational Change Management
10 Glossary and Appendices
Appendices can help the document flow better, especially during the analysis and justification sections (i.e. during the ‘argument’ parts) by extracting information out of the body of the document for reference. For example, the following may be useful:
• a detailed cost/benefit analysis for each option and any relevant estimates (only if required, for large projects only);
• a risk analysis of the options; or
• a glossary, if there are a lot of terms or concepts that are likely to be unknown or confusing (such as acronyms).
Appendix A: Benefit Analysis
For each option, assess how each key stakeholder group (or individual stakeholders) may be impacted by the project and how they may impact on the project. This may be positive or negative. Allocate a rating, High = 3 etc., and total in the right column. For larger projects, it may be necessary to assess each major benefit/disbenefit for each option.
Option …<# - Description>…………………..…
Positive Impact Negative Impact
Major Stakeholder High
(3) Medium
(2) Low
(1) Nil
(0) Low
(-1) Medium
(-2) High
(-3) Rating
Customer Impacted By Project 2 1
Impact On Project -1
Business Owner Impacted By Project 3 4
Impact On Project 1
Impacted By Project
Impact On Project
Impacted By Project
Impact On Project
Total 5
A.1 Summary of Options
For each stakeholder group, transfer the total ratings onto this sheet to give a direct comparison between the options.
Stakeholder Option 1 Option 2 Option 3
Appendix B: Risk Analysis
For each option, fill in the worksheet on the next page with the major risks.
1. For each risk work out, what grade there is associated with it. This is only a quick estimate using the table below to produce an A to N grading. Ignore those risks with a grading of D and N. (Refer to the Project Management Fact Sheet: Developing a Risk Management Plan for more details)
2. For the A and B gradings, estimate what minimisation and mitigation strategies should be put in place, their cost and the resultant grading (i.e. the impact of the strategy).
3. For each grading, allocate a numerical rating, e.g. A=5, B=4, C=3, D=2, N=1.
4. Add these together to get a total grading for each risk. The higher the total score the higher the level of risk.
5. Add the scores for each risk to get a total for the option. This allows a comparison to be made between options as to the comparative level of risk of each option.
Likelihood Low Medium High EXTREME
Low N D C A
Medium D C B A
High C B A A
Option ……………………………………………………………..…
Risk Rating
Major Risks Initial Grading Strategy Cost Resultant Grading Rating
New system instability causes increased resource requirements C N/A C 3
Not able to meet the major user requirements A Use a detailed acceptance testing plan and verify each phase 5000 C 3
There are no net improvements for the users C N/A C 3
Customers are inconvenienced by the system and thus there is bad publicity B Use a newsletter to keep the customers informed 2000 D 2
Total $7000 11
Order Now

Calculate a fair price for your paper

Such a cheap price for your free time and healthy sleep

1650 words
Place an order within a couple of minutes.
Get guaranteed assistance and 100% confidentiality.
Total price: $78
WeCreativez WhatsApp Support
Our customer support team is here to answer your questions. Ask us anything!
👋 Hi, how can I help?