Project Business Plan

(MediumProjects)

Template and Guide

Version 2, April 2008

This Template and Guide is for the development of a Project Business Plan for a medium sized project. The Guide is intended to be read in conjunction with the Template and should be removed from the front of the final document.

Other templates and guides for the development of a Project Business Plan for a larger, more complex project (Project Business Plan - Large) or a small project (Project Business Plan - Small) have also been developed. Please refer to Project Management Fact Sheet: Project Sizing to determine your relevant Project Business Plan. These are available at

/ License URL:
Please give attribution to: © State of Tasmania (Department of Premier and Cabinet) 2017

PM 904 Project Business Plan (medium projects): Guide

Tasmanian Government Project Management Framework

1

What is a Project Business Plan?

A Project Business Plan is the management document for the project. It is owned, maintained and utilised by the Sponsor[1] to ensure the delivery of project outputs and the realisation of project outcomes.

The Project Management Fact Sheet: Project Sizing can assist you to determine the size of your project.

Why would you develop a Project Business Plan?

A Project Business Plan is developed to provide:

  • Comprehensive overview of all the project components, how you intend to produce the outputs and describes the roles and responsibilities of each of the parties in the governance structure of the project.
  • The project’s Sponsor with a documented framework to ensure the achievement of defined project outcomes and to effectively monitor the project from start to finish.
  • A formalised agreement between the Project Sponsor and the Project Manager of what needs to be done and when.

The document expands upon the original Project Proposal or the approved option in the Project Business Case enabling detailed definition of the scope and management of the project.

When would you develop a Project Business Plan?

Approval to proceed to develop a Project Business Plan is usually obtained from the acceptance or approval of a preceding stage such as a Project Proposal, Project Business Case or Feasibility Study. The Project Business Plan expands the approved proposal developed in these documents in order to:

  • Provide specific details on the scope, governance, budget, resources, work plan and milestones of the project.
  • Define the project and quality management processes to be used throughout the project.
  • Gain authorisation to proceed to the next step of the project.

What you need before you start:

  • Agreement to proceed with the development of the Project Business Plan from the Project Sponsor or Proposer.
  • Knowledge and understanding of the development of a Project Business Plan, as outlined in the Tasmanian Government Project Management Guidelines Version 6.0, 2005.
  • Any other project approval processes that are required in your organisation.
  • Endorsed document establishing the scope of the Project Business Plan, which could be a Project Proposal or a Project Business Case, or as simple as an email from your manager.

Also advisable:

  • Knowledge and understanding of project planning, scope definition, stakeholder identification, risk identification and the development of work breakdown structures.
  • Awareness of the environmental factors that may affect the project such as political, industrial, legislative, technical, financial, social, cultural and security/privacy.
  • Corporate/Business Plan for the Department/Business Unit.
  • Departmental Project Management Guidelines.

What you will have when you are finished:

  • A complete Project Business Plan that is ready for acceptance by the Project Sponsor/Steering Committee.

Integration Process:

Any endorsed documents (for example a Project Proposal, Project Business Case or an email from your manager) should be utilised to populate the Project Business Plan. This information, along with any gaps, then provide a basis for further discussion, clarification and confirmation of the project scope.

It should be noted that development of the Project Business Plan is not a staticprocess, and that all aspects described in the Business Plan must be re-examined many times over the life of the project, particularly where a great deal of change is involved. This iterative development should involve the Project Sponsor. The key is to obtain clear sign-off where scope changes are required during the life of the project.

Maintaining document control:

In order to track the agreed changes to the Project Business Plan, and record its distribution throughout the document's development and subsequent revision(s), a document version control process is essential. Version control provides for unique identification of documents, whether electronic or hard copy, and assists with the easy identification of each subsequent version of a document. The version number changes as the document is revised allowing released versions of a document to be readily discernable from draft versions.

Refer to the Project Management Fact Sheet: Document Controlat more information.

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 <angle brackets> 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

The following tools and resources are available at

  • The Project Management Fact Sheet: Developing a Project BusinessPlan provides additional detail on the steps involved in developing a Project Business Plan.
  • The Project Status Report: Template and Guide
  • Further information on stakeholder management is contained within the Tasmanian Government Project Management Guidelines - Section 5: Stakeholder Management and the Project Management Fact Sheet: Developing a Project Communication Strategy.
  • Further information on assessing the project’s exposure to risk is contained within the Tasmanian Government Project Management Guidelines – Section 6: Risk Management and the Resource Kit: Risk Management.

Checklist

Have you remembered to remove:

  • The versioning statement from the front cover of your document?
  • Thisguide and checklist from the front of your document?
  • All blue italic instructional text and prescriptive text enclosed in angle bracketswithin the template?

PM 904 Project Business Plan (medium projects): Guide

Tasmanian Government Project Management Framework

1

Project Title>
Project Business Plan
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

enter name of unit

Department of enter name of department>

Version No: <n.n> <dd-mm-yyyy
Copy: Uncontrolled

1

Document Acceptance and Release Notice

This document isVersion No <n.n> <dd/mm/yyyy of the <Project Title> Project Business Plan.

The Project Business Plan is a managed document. For identification of amendments, each page contains a release number and a page number. Changes will only be issued as a complete replacement document. Recipients should remove superseded versions from circulation.

This document is authorised for release once all signatures have been obtained.

PREPARED: / Date: / - / -
(for acceptance) / <Project Manager Name, Title>
<Project Title> Project Manager
ACCEPTED: / Date: / - / -
(for release) / <Project Sponsor Name, Title>
<Project Title> Project Sponsor

1

Document Development History

Build Status:

Version / Date / Author / Reason / Sections
<n.n>
List the most recent amendment first / <dd-mm-yyyy> / <name> / Initial Release / All

Amendments in this Release:

Section Title / Section Number / Amendment Summary
eg: This is the first release of this document.

Distribution:

Copy No / Version / Issue Date / Issued To
1 / <n.n> / <dd-mm-yyyy> / <name, title, organisation>
2
Electronic / <n.n> / <dd-mm-yyyy> / Shared drive

1

Table of Contents

1 Overview

1.1 Purpose of Business Plan

1.2 Project Title

1.3 Initiation & Background

2 Objectives and Scope

2.1 Objectives

2.1.1 Corporate Objective(s)

2.1.2 Project Objective(s)

2.2 Outcomes

2.3 Outputs

2.4 Scope of Work

2.5 Project Development Plan

2.6 Assumptions and Constraints

2.6.1 Assumptions

2.6.2 Constraints

2.7 Relevant Government Policy, Legislation and Rules

3 Project Management Plan

3.1 Governance

3.1.1 Project Sponsor

3.1.2 Project Business Owners

3.1.3 Steering Committee

3.1.4 Project Manager

3.1.5 Project Team

3.1.6 Consultants and Contractors

3.1.7 Reference Groups

3.1.8 Working Groups

3.2 Reporting Requirements

3.2.1 Reports to the Steering Committee

3.2.2 Quality Consultants’ Reports

4 Stakeholder Management & Communication

5 Related Projects & Programs

6 Resource Management

6.1 Budget and Expenditure

6.2 Other Resources

7 Risk Management Plan

8 Quality Management Plan

9 Organisational Change Management & Outcome Realisation

10 Evaluation

11 Project Closure

12 Appendices

1

Appendices

1 Overview

1.1 Purpose of Business Plan

The Project Business Plan is the management document for the project. It is owned, maintained and utilised by the <Project Title> Steering Committee to ensure the delivery of project outputs and the realisation of project outcomes.

The document will be reviewed and amended to meet changed conditions or objectives during the project’s life span.

1.2 Project Title

<Project Title>

1.3 Initiation & Background

Briefly describe the reasons for establishing the project and how it was initiated. Summarise any relevant background information. This section may include an examination of the various options considered during the feasibility phase of the project. Additional information may be included in the Appendices.

2 Objectives and Scope

2.1 Objectives

A project objective is a statement of the overarching rationale for why the project is being conducted. A project can have one or more objectives. They do not need to be measurable, and they should focus on what the project is going to achieve, rather than what is produced. A useful way to frame the objective is to answer the question 'why are you doing the project?' The result is a one sentence statement, or series of statements, starting with the word 'To'....

Project Objectives should be directly related to the Corporate Client’s Corporate Objectives and the business driver(s) for the project. An Objectives Hierarchy illustrates the links between the project’s activities and the client organisation’s goals and strategic direction, providing the context in which the project is being undertaken. Reporting on the project’s relationship to these corporate objectives will become part of the focus of project closure.

For example:

Corporate Objective:To develop and maintain a best practice project management framework and methodology to be adopted across government

Project Objective:To improve accessibility to, and quality of, information on project management tools and techniques and on available training for project participants.

2.1.1 Corporate Objective(s)

Enter any relevant departmental and/or divisional goals here.>

2.1.2 Project Objective(s)

The objective(s) of the <Project Title> are :

  1. To <enter Objective 1>
  2. To <enter Objective 2, if applicable>

2.2 Outcomes

Outcomes are the benefits or other long-term changes that are sought by undertaking the project. They are achieved from the utilisation of the project's outputs by project customers. If the outcomes are achieved then the project's objectives have been met. To define outcomes, ask what the project is going to achieve for the corporate stakeholders.

While there is often one or more overarching outcomes/benefits sought from undertaking the project, it is important to isolate a small number of specific, quantifiable outcomes from within this. These ‘Target Outcomes’ are what the project will be held accountable for. Target Outcomes have a measurable benefit and will be used to gauge the project’s success. Target outcome measures will help answer such questions as 'what have we achieved?' and 'how do we know?’ Target Outcomes are expressed as a statement in the past tense and usually start with a word ending in 'ed’.

To make target outcomes quantifiable requires an analysis of the current situation, including a benchmark or baseline against which to measure, and a methodology for measurement. A pro forma for documenting Target Outcome Measures is provided at Appendix A.

For example, broader outcomes may be:

  • Improved standards for project management across the Tasmania State Service
  • Increased knowledge and skills in project management methodology, through training and development covering all project participants

Target Outcomes may be:

  • Improved quality of information and resources relating to project management tools, techniques, processes and training needs for project participants
  • Improved accessibility of information and resources relating to project management tools, techniques, processes and training needs for project participants
  • Greater recognition of the PDMU as a source of high quality information and resources relating to Project Management.

The broad outcome for the <Project Title> Project is:

  • enter outcome

The Target Outcomes for the Project Title> are:

  1. <enter Target Outcome 1>
  2. <enter Target Outcome 2 and more, as required >

These Target Outcomes comprise performance information against which the project will be assessed and are detailed in Appendix A.

2.3 Outputs

Outputs are the products, services, business or management practices that will be required (produced) to meet the identified project outcomes/benefits. They may be new products or services, or revisions of existing operations. Outputs link with outcomes, in that the outputs are used by the project's customers to achieve the outcomes. Ask ‘What’ new services, businesses, or management practices will need to be implemented to meet the identified outcomes. Output statements are kept as free as possible from system terms and are usually expressed as nouns.

For example:

  • A new financial management policy, procedures and standards manual
  • A new legislation storage and access facility
  • A decentralised enquiry and reporting facility for internal use

Consider how stakeholders will utilise each output to achieve project outcomes. While there is never a direct one-on-one relationship, the use of a Customer Map can assist in identifying Target Outcomes and Outputs. This is provided at Appendix B.

It is important to note that project documentation (such as a Project Business Plan or Risk Management Strategy) is not considered an output. Project documentation is the by-product of efficient project management.

The following outputs are to be delivered by the project:

  • List the Outputs to be delivered by the Project. Include descriptions where necessary.>

The customer map at Appendix B illustrates the relationship between the utilisation of outputs and the achievement of outcomes.

2.4 Scope of Work

The scope of work is defined as a clear statement of the areas of impact and the boundaries of the work of the project. The following model will help to identify all of the project work that clearly falls within the scope of the project, that which is outside the scope, and any work that requires further consideration. Reviewing the Customer Map (see Appendix B) may assist in clarifying what is inside or outside the scope.

Where the project is dependent on other work being completed (i.e. outside the scope of the project), agreement must be sought in terms of who is responsible and timelines for completion. At the time that the Project Business Plan is endorsed by the Steering Committee as Version 1.0, there should be no work that remains uncertain or unresolved – it should be either inside or outside scope.

Table 1: <Project Title> Scope of Work
Part of the Project
(Inside Scope) / Responsibility / Not Part of the Project
(Outside Scope) / Responsibility / Uncertain or Unresolved
Training operational staff to use the new system / Project Manager
Updating the induction manuals / HR Section / timeline for completion

2.5 Project Development Plan

How is the development process to be undertaken to produce the project outputs? How will the Project Manager ensure that the project’s development is on track? A Project Development Plan will set a course for the project and ensure that the project’s progress can be monitored and reviewed by the Steering Committee.

If the outputs are more complex, involving multiple teams, long periods of time, or dependent on the delivery of other outputs, a Project Development Strategy should be devised to ensure that the project’s progress is systematically planned and reviewed. Depending on complexity, the development strategy may adopt a phased approach or may be planned in stages[2]. The use of Gantt Charts to graphically represent the development of each phase or output against the timeframe may also be considered useful in this instance[3]

For medium sized projects, a Project Development Schedule, reflected chronologically as in the table below, listing major activities and milestones may be sufficient to set the project’s course and monitor progress. Milestones are shown in bold and indicated by a blank scheduled start date, these are the dates identified during the initial planning stages for the project’s key deliverables.

The initial detailed Project Development Plan can be included as an appendix in this Project Business Plan. However, a working Project Development Plan should be maintained separately to avoid the need to continually re-release the Project Business Plan.

Table 2: <Project title> Project Development Schedule

Id / Description / Who / Scheduled Start / Scheduled Finish / Predecessor[4]
1 / Formal approval to commence project obtained / 1 July 2007 / -
2 / Complete consultants brief for documentation of current processes / Project Team / 1 July 2007 / 1 Aug 2007 / 1
3 / Document current processes / Consultant / 1 Aug 2007 / 1 Sept 2007 / 2
4 / Review of present processes documentation with Stakeholders / Project Manager / 1 Sept 2007 / 10 Sept 2007 / 3
5 / Investigate and develop enforcement methodology options / Project Manager / 1 July 2007 / 1 Sept 2007 / 1
6 / Decide on preferred option for development of business process / Steering Committee / 1 Oct 2007 / 5

2.6 Assumptions and Constraints

It is essential that assumptions made during the planning process are recognised and recorded in the Project Business Plan along with any constraints. This process should also assist with risk identification, as both assumptions and constraints will reveal areas of risk for the project.