CLIENT NAME

Department/Programme N
Summary byline

Project Brief
Name of Project (Project Code XXXOOO)

Version: 0-01 DRAFT

Document Security: CONFIDENTIAL Presented by Full Name, Title Presented to Full Name Title Date: 12 June 2012

Table Of Contents

contents

heading
Document Control

page no.
3

Background
About the Client The Purpose of this Document Reference Documents

4
4 5 5

Project Definition
Objectives Scope Outline project deliverables Exclusions Constraints Interfaces

6
6 7 8 8 9 9

Outline Business Case Project Tolerances Customer's Quality Expectations Acceptance Criteria Known Risks Annexes
Annex A: Annex B: Annex C:

10 13 14 15 16 18
18 18 18

Document Control

DOCUMENT CONTROL
Document Storage
Document title: Author: Last Updated: Created on User Last Saved by: 100129809.doc

Version Control Log

Version v0-01 v0-02 Author Description of Changes Date

Document Circulation
Organisation Dept. Person Title

Copyright & Legal

This report, prepared specifically for [CLIENT NAME], is the intellectual property of [YOUR ORG]. It is protected by copyright and it is presented in circumstances of complete confidentiality. It must not be given, reproduced, or disseminated, to any person, public authority, institution or organisation without the express consent of [YOUR ORG] in writing. In no event shall [YOUR ORG] be liable to anyone for special, incidental, collateral, or consequential damages arising out of the use of this information. Many designations used by manufacturers and sellers to distinguish their products are claimed as trademarks or other proprietary rights. Where designations appear, and when the editorial staff were aware of a claim, the designations have been shown. Other trademarks, registered trademarks, and service marks are the property of their respective owners. Copyright 2008 [YOUR ORG]. All rights reserved. Originated in [OFFICE LOCATION].

Department / Programme Name

Background

Brief outline of any background to the Project / (business / political) context. Include brief outline of rationale, who commissioned by, drivers etc. Where does the project fit within wider picture? Context Stakeholder Internationa Political Legal/Regul Economic Technologic Internal Environment Competitor Customers Suppliers Strategic Regulators

atory

Allies

Owners Employees

Board of Directors Culture

al

Sociocultural

ABOUT THE CLIENT

Enter communications boilerplate

About Your Organisation

Enter communications boilerplate

About the Programme

Enter communications boilerplate

Department / Programme Name

Project Name and Project Code

About the Project

Enter communications boilerplate

THE PURPOSE OF THIS DOCUMENT

A Project Brief is a formal statement of the objectives and functional and operational requirements of the finished project. It contains the required detail to enable the project planning team to execute the detailed design and specification of the work.

REFERENCE DOCUMENTS
This project brief is in response to the following documents:

Document #1 Document #2

Department / Programme Name

Project Name and Project Code

Project Definition

OBJECTIVES
Depending on the context upon which your project is founded will depend on who sets your objectives. This said, it is the responsibility of the Project Manager to ensure that the objectives are workable and S.M.A.R.T.. If the PM has to set them or has had them handed down from senior management or programme management, the PM needs to review the projects objectives and redraft them if necessary to ensure that they are exact and achievable. Dont forget to re-communicate them they are no good in the bottom of your drawer. Evaluate the project objectives using the following considerations. Specific - A specific objective has a much greater chance of being accomplished than a general objective. To set a specific objective you must answer the six "W" questions:

Who: Who is involved? What: Where: When: Which: What do we want to accomplish? Identify a location. Establish a time frame. Identify requirements and constraints.

Why: Specific reasons, purpose or benefits of accomplishing the objective. Measurable - Establish concrete criteria for measuring progress toward the attainment of each objective you set. To determine if your objective is measurable, ask questions such as......How much? How many? How will I know when it is accomplished? Agreed - it is crucial that agreement is reached between all stakeholders on what the projects goals should be. Realistic - To be realistic, an objective must be something your project and your organisation are both willing and able to work. To you have the right resources and funding? Has your organisation taken ownership of the project?

Department / Programme Name

Project Name and Project Code

Time-based - A objective should be grounded within a time frame. With no time frame tied to it there's no sense of urgency. For example, a business units goal maybe Keep our departments web page up to date. A more effective goal would be, To solicit updates and new material from our departments managers for the web page on the first Friday of every month in order to publish this new material no later than the following Friday.

SCOPE
Time, quality and cost are a function of scope. Therefore if you get scope wrong, the time, quality and costs will be wrong.

Figure 1: The project scope relationship

In determining scope the project manager must develop common understanding as to what is included in, or excluded from, a project. Only then, once your have defined the scope, you can calculate cost, quality and time. There are numerous ways to define. Ideally several ways should be used. Each looks at the situation from a different perspective and will elicit different information. We look at three main ways are:

Define Deliverables What training is required? What documentation is required? Define Functionality and Information What business procedures are required? What operations procedures are required? What are the critical requirements? Will Systems Analysis be required, if so whats needed? Define Technical Structure Will an Acceptance Test Plan and testing be required?

Scope definition deals with "What" and Why" and is a function of Quality, Cost and Time.

What is the main or overall goal

7

Department / Programme Name

Project Name and Project Code

what is the background what opportunity/problem is to be solved What is the "fit" with corporate strategic goals? What other related projects are in process? What changes will come about as a result of the project? What are the Go/No-go criteria for implementation? What are the specific objectives? efficiency? ROI? What are the measureable outcomes? or specific deliverables? What are the priorities? What is included? or not included? limits to your authority? What are the options? What are the assumptions? What are the Key Performance Indicators? Why is this a project in the first place? why is it needed? Why are the limits set as they are? who is setting them? Why are there politics involved? and who are the stakeholders?

Why are some stakeholders against the project? who are they? how might they influence the outcome?

OUTLINE PROJECT DELIVERABLES

At this early stage of the project, list the expected project deliverables and try to be as specific as possible. Consider the following:

The deliverables within the scope considered.

The opportunities that would be lost/missed if the project did not happen.

EXCLUSIONS
What activities have been excluded from the project? The scope of the project can be defined by what will not be implemented as much as by what will be included. This may be due to budgetary constraints, the overlapping with another project or be part of a future phase. This is a very important section as it will define and communicate which deliverables the reader might have expected to be part of the project but are considered outside the projects current scope.

Department / Programme Name

Project Name and Project Code

CONSTRAINTS
This section can expressed the constraints in terms of project, operational, technical, business and external constraints. However at a minimum the following should be addressed:

Resources What is the resource availability of skilled team members? Time - What is the latest project completion date? Quality What is the basic minimum standard of delivery? Cost - What is the maximum cost of the project?

INTERFACES
Projects do not exist within a vacuum. What organisations, both internal and external, does the project interface with? What are the job titles of the primary and secondary contacts? Names of people should be avoided as people can change jobs during the course of the project.

Department / Programme Name

Project Name and Project Code

Outline Business Case

This section is only an outline and designed to take the basic elements of the business case found in the Project Mandate and build on them so the Project Brief contains sufficient information for the Boards authorisation in DP1. The detailed business case will be fleshed out at a later stage in IP3 Refining the Business Case and Risks as part of the Project Initiation Document. The business case is a living document and will be revised for each End Stage Report as well as being updated on an adhoc basis as project issues impact it. This outline business case should, at a minimum, the following:

The reason(s) for undertaking the project - a description of how this project supports business strategy, plans or programmes the reason for selection of this solution The expected benefits (include who it will benefit and in what numbers). How long following completion of the project its benefits will still be felt. An estimation of likely cost and timeframe, with all relevant justification.

Estimate Cost
The following table is the estimated cost for the project: Budget Item Staff Cost Consultant Costs Equipment Services Other Direct Costs Programmable Budget Administration Costs TOTAL $ USD

Department / Programme Name

10

Project Name and Project Code

Department / Programme Name

11

Project Name and Project Code

Timeline
The proposes project will be rollout to the following timetable:

Department / Programme Name

12

Project Name and Project Code

Project Tolerances

No project ever goes to plan. The projects tolerances are an important component of the management by exception concept and provide the Project Board with the ability to set boundaries in which the Project Manager can operate and accept deviations without requiring attention from the next higher authority.

Figure 2: The tolerance delegations and deviation reporting

There are two standard elements of tolerance, (1) Time and; (2) Cost. However there are many other ways of expressing tolerances:

Risk Tolerances sometimes referred to as the risk appetite Scope Tolerances Benefit Tolerances

Department / Programme Name

13

Project Name and Project Code

Customer's Quality Expectations

The essence of the quality approach in Prince2 is 'fitness for purpose', achieved through combining the customer's quality expectations, and the means to achieve them, with the existing quality policy, processes and procedures of the organisation into a Quality Plan which will set out the project's approach to quality. The approach is based on four elements:

A quality system, comprising an organisation structure, processes and procedures, which may exist on both customer and supplier side of the project. One or other can be chosen as the basis for the project quality plan, or a combination of the two.

A Quality Assurance (QA) function which creates and maintains the quality system, for example an internal QA department, and which monitors the implementation of a project's quality plan. Quality Planning, based on understanding of the customer's quality expectations in Starting Up a Project, and a Quality Plan produced as the first step in Initiating a Project. The quality plan produced here will inform the planning of the project from that point on.

Quality Control, which is the means by which products are checked for compliance to their product descriptions, the plans for which are elaborated when constructing the detailed stage plans.

Department / Programme Name

14

Project Name and Project Code

Acceptance Criteria

Defining the acceptance criteria is another very important aspect which follows on from defining the Customers quality expectations. Input from the senior user is also very important. Following on from the definition of the Customers quality expectations the following criteria are the acceptance criteria for the project.
Criteria Target dates Value 6 months Pilot 12 Months Full communications roll out Create, Edit, Remove, Search pages Undefined Undefined Undefined Undefined Undefined Undefined Undefined Undefined Undefined Undefined Undefined

Major functions Appearance / Ease of use Personnel level required to use / operate the product Performance levels Capacity Accuracy Availability Reliability (mean/max time to repair, mean time between failures) Development costs Running Costs Security Timings

All the criteria need to be measurable and realistic. Use the S.M.A.R.T. method to assist you in defining, in detail, the acceptance criteria.

Department / Programme Name

15

Project Name and Project Code

Known Risks

In prioritising risks, remember that many of them overlap. For example any risk to reputation may have an impact on competition, strategic, legal or financial risk. Environmental risk will almost certainly impact reputation risk. In prioritising a key risk, many other lower level risks may also be impacted. Strategic Risk Hazard Risk Risk Category Property Casualty Political Environmental Regulatory Financial Currency Interest Rate Commodity Prices Credit Fraud Operating Risk Inventory Supply Chain Capacity Information Systems Organisational Risk Governance Gaps Wrong Org Structure Talent / Morale M & A Integration Strategic Risk Industry Economics Collapse Technology Shift Brand Erosion One-of-a-kind competitor Customer priority shift New project failure Market stagnation Risks

Department / Programme Name

16

Project Name and Project Code

Department / Programme Name

17

Project Name and Project Code

Annexes

ANNEX A:

ANNEX B:

ANNEX C:

Department / Programme Name

18

Your Organization Name Department / Programme Name Head Office Address 1 Address 2 Town / City, Postcode Country

To learn more visit www.domain.com

For more information on this document please contact the following people:
Full Name Project Manager +xxx xxx xxx [email protected]

Full Name Project Office Manager +xxx xxx xxx [email protected]