Project Brief Template

PROGRAMME NAME

PROJECT BRIEF[A1]

Project Title

Release Status: DRAFT, REVIEW, FOR INFORMATION or FINAL

Author: Insert Name

Date:01 January 2016

Filename & Version: Insert details

Project ID: Insert ID

Methodology: PRINCE2™ 2009

FMD Consultants Limited assumes no responsibility for the usage of any information contained in this document and the way it is handled and disclaims all liability in respect of such information and its provision. Subject to this disclaimer, you may copy and utilise the material contained in the document.

This information is based on OGC PRINCE2™ material. PRINCE2™ is a registered trade mark of the Office of Government Commerce in the United Kingdom and other countries. All registered trademarks recognised & accepted.

1Document History

1.1Location

This document is stored in the following location:

Filename
Location

1.2Revision History

This document has been through the following revisions:

Version No. / Revision Date / Filename/Location stored: / Brief Summary of Changes

1.3Authorisation

This document requires the following approvals:

AUTHORISATION / Name / Signature / Date
Executive
Senior User
Senior Supplier

1.4Distribution

This document has been distributed to:

Name / Title / Version Issued / Date of Issue

1.5Related Documents

Summary of filenames and locations of related documents:

Document Type / Filename/Location stored:
Project Mandate
Project Product Description
Outline Business Case
Project Management Team Role Descriptions
Lessons Log

2Contents

1Document History

1.1Location

1.2Revision History

1.3Authorisation

1.4Distribution

1.5Related Documents

2Contents

3Purpose

4Project Definition

4.1Background

4.2Project Objectives

4.3Outline Project Deliverables / Desired Outcomes

4.4Scope and Exclusions

4.5Constraints and assumptions

4.6User Groups and Other Interested Parties

4.7Project Tolerances

4.8Interfaces

5Outline Business Case

6Project Product Description

7Project Approach

8Project Management Team Structure

9Project Management Team Role Descriptions

10Additional Role Descriptions

11References

3Purpose

The objective of the Project Brief is to enable a controlled start to the project by ensuring that adequate information is documented to inform all necessary persons that a new project is underway. A Project Brief is a key document that gives a description of what the project is to do and is intended to achieve. It is effectively a Mini Project Identification Document. The purpose of the Project Brief is for the Project Manager to write a detailed foundation of the project, covering the project’s scope. This will then be submitted to and assessed by the Project Board. If the project isconsidered to be justifiable, the Project Board should authorise the initiation of the Project. When and if authorisation is received, the Project Manager shouldstart preparing the Project Initiation Document (PID). The contents of the Project Brief will be extended and refined into the Project Initiation Document.

4Project Definition

4.1Background[A2]

4.2Project Objectives[A3]

4.3Outline Project Deliverables / Desired Outcomes[A4]

4.4Scope and Exclusions[A5]

4.5Constraints and assumptions[A6]

4.6User Groups and Other Interested Parties[A7]

4.7Project Tolerances[A8]

4.8Interfaces[A9]

5Outline Business Case[A10]

6Project Product Description[A11]

7Project Approach[A12]

8Project Management Team Structure[A13]

9Project Management Team Role Descriptions[A14]

10Additional Role Descriptions[A15]

11References[A16]

Project ID: / Doc Ref:
Project Brief / Page 1 of 5 / Date of Issue:

[A1]General Guidelines:

This document provides a template for the creation of a Prince2 Project Brief conforming to the Office of Government Commerce (OGC) guidelines.

Please note that Section 3, Purpose of the Project Brief, does not form part of the OGC guidelines but has been included to ensure the final document is appropriately focused.

Each section has comments which give guidance on the structure, content or options for that section. Whilst the comments reflect the OGC guidance, additional information in the form of examples, suggestions for content and areas for consideration have been provided.

Comments can be managed via the ‘Review’ tab within MS Word. All comments can be displayed in a reviewing pane (horizontal or vertical) by clicking on the Reviewing Pane icon within the Review Tab. Individual comments or all comments can be deleted via the Delete icon in the Comments box on the Review Tab.

The Project Brief can be printed without comments by selecting the “Print what” dropdown on the Print screen and choosing “Document” rather than “Document showing markup”.

It may be appropriate to delete all guideline comments before the Project Brief is circulated for review, at which point reviewers will add their own review comments.

[A2]Background:

Give a brief summary of why the project is needed (ideally documented in the Project Mandate).

Summarise dates of project instigation and approval stages along with approving authority

[A3]Project Objectives:

What is the project intended to achieve. Typically this can encompass regulatory changes, cost savings, increase in profitability, provision of new products or services, improvement in customer services or expansion of market share or demographics. This should cover time, cost, quality, risk and benefit performance goals

[A4]Outline Deliverables:

What is the product intended to deliver to the users i.e. what is the mechanism of achieving the Project Objectives

[A5]Scope and Exclusions:

How far does the scope of the project spread. Are there areas which are specifically excluded from this scope

[A6]Constraints and Assumptions:

Are there any constraints applied to the project which are within the control of the project and outside the control of the project. Have any assumptions been made which need to be ratified at a later date through further investigation, analysis or prototyping of prospective solutions. What impact are these constraints and assumptions likely to have on the project’s viability

[A7]User Groups:

Whom will be using the projects products or will be directly impacted by their usage. What parties will have an interest in the impact of the products

[A8]Project Tolerances:

Based upon the areas of the project which are known and understood along with those which are either not known or not calculable, what tolerances (typically + or - %) are to be approved for cost and time before the deviation must be escalated to the next level of management. There may also be tolerance levels set for quality, scope, benefit and risk. In addition, tolerance may be applied at project, stage and team levels

[A9]Interfaces:

What interfaces (inwards and outwards) is the project likely to have. This should be a comprehensive list in order to ensure the structure, frequency and communications method of each interface is stable and clearly defined

[A10]Outline Business Case:

At this Project Brief stage the Outline Business Case should have been documented and approved by corporate or programme management. This should be copied into this Project Brief. Note that several areas may be the basis of other sections in this Project Brief thus should not be repeated in this section

[A11]Project Product Description:

At this Project Brief stage the Project Product Description should have been defined and approved by the Executive. This should incorporate the customer’s quality expectations, user acceptance criteria, and operations and maintenance acceptance criteria. This should be copied into this Project Brief and checked to ensure there are no duplications with other sections

[A12]Project Approach:

This defines the choice of solution the project will use to deliver the business option selected from the Business Case and should take into consideration the operational environment into which the solution must fit. For example, will the solution be developed in-house, contracted to a third party, modification of an existing product or designed and constructed from scratch. Will it be a COTS package, designed from scratch or a COTS package with bespoke modifications

[A13]Management Team Structure:

At this Project Brief stage the Management Team Structure should have been documented and approved by the Project Executive. This should be copied into this Project Brief.

[A14]Role Descriptions.

At this Project Brief stage the Role Descriptions for the proposed project team should have been documented and approved by the Project Executive. This should be copied into this Project Brief.

[A15]Additional Role Descriptions:

Standard Prince2 Project Management Team consists of the Project Board (Executive, Senior User(s), Senior Supplier(s)), Project Assurance, Change Authority, Project Manager, Project Support and Team Manager(s). At this stage of the project requirements for additional specialists may be highlighted, for example technical representation if there are complex technical elements of the project. These roles should be defined although it may not be practical to allocate the role to an individual at this stage

[A16]References:

Provide references to any associated documents or products which may be appropriate to the project or mentioned in the Project Brief.