The Project Brief

The Project Brief
By Mark Norman

The Project Brief is a key quality document used when we begin a project, it is a powerful tool and there to help us. Its purpose is to provide a clear definition of the project’s direction and scope and forms the ‘contract’ between the project team and corporate management. Once the document has been approved, any significant change to the material contained in the Project Brief will need to be referred to corporate or program management for re-approval.

The document will define the requester’s acceptance criteria and the required final objectives and outcome. It will detail the constraints and assumptions that impact on those responsible for the project. It will also highlight an outline business case along with any known risks. This level of detail will allow management to make a considered decision on whether to proceed with the request.

On gaining approval to proceed, the contents of this document will be used to form the Business Case as well as the Project Initiation Document.

1 – Background

This section should provide:

• Who / which department has raised the request and who will be its sponsor.

• A brief description of the project and the reasons behind it being requested

• Any previous reports, documentation etc that might impact on the development.

2 – Objectives

This section should provide:

• Specifically what is required to be achieved by the project, expressed wherever possible, in measurable terms; it is often helpful to identify separate objectives for the project itself (eg: target dates, expenditure profiles) and the project outcome (what the end-product is required to deliver during its life.

3 – Scope, Exclusions and Interfaces

This section should provide:

• Specific identification of items, areas, functions, processes, etc that will be included In the project

• Specific identification of items, areas, functions, processes, etc that will not be included in the project

• Specific identification of all interfaces to other systems that will be affected along with an indication of any necessary changes to the interface/other system to accommodate the project deliverables.

4 – Outline Deliverables

This section should provide:

• A list of the expected and required Deliverables/Products/Outcomes that the proposed project must create, change or acquire.

5 – Constraints

This section should provide:

• Details of any restrictions / limitations placed on the project; these could be related to time, resources, funding or fixed and inflexible delivery dates.

• Restrictions / limitations imposed by other projects

• Restrictions / limitations imposed by 3rd party companies

6 – Assumptions

This section should provide:

• Details of any items, resources, events or situations that are expected to be in place or having occurred prior to the project commencing. This may include steps to mitigate identified preliminary risks.

7 – Outline Business Benefits/Business Case

Comments made in this section need only be brief. Should initial approval to proceed be granted, a formal Business Case will be required which will give the requester the opportunity to expand on these comments. You are encouraged however to give considered thought into defining, quantifying and measuring benefits as this will form a key part of the approval process as well as the core basis for post project review and whether the project achieved it’s objectives.

The following flow is a simple guide to help you understand what a benefit is:

Business driver >> Project requirement >> Business change >> Project objectives >> Business benefits

This section should provide:

• A description of how this project supports business strategy, plans or program.(Specifically state the strategies that are supported)

• Specifically state what business benefits will be gained from the objectives you listed in Section 3. A project objective is not a business benefit; a project objective is a trigger to one or more business benefit(s).

• Specifically state whether these benefits can be quantified and are measurable

• For each business benefit described, please state who will take responsibility and ownership of it and will measure the benefit.

8 – Preliminary Risk Assessment

This section should provide:

• Details of any risks identified after undertaking an initial risk assessment. Each risk should be qualified in terms of likelihood of occurring and its impact if it did occur. You should also provide a recommendation for mitigating each risk.

9 – Customer’s Quality Expectations

Quality is a quantifiable and measurable attribute and as a general rule of thumb the higher the quality, the more time, effort and budget is needed to achieve it.

You should avoid making a general statement here like “the product needs to be high quality” but instead state the recipients expectations in terms of the deliverables’ look, feel, operation, performance etc.

10 – Acceptance Criteria

This section should provide:

• A clear and concise definition of the level of performance the deliverables must consistently meet for the recipient to accept and take ownership of the deliverables and see the project move into the project closure stage.

11 – Outline Project Plan

This section should provide:

• A brief statement of the proposed start and finish dates, likely review points, frequency of updating the plans with “actuals”, and Team reporting arrangements

• The likely resource requirements

• The likely budgetary requirements

• You may want to include a Gantt chart or activity plan to visually represent the project

This is the content I add to my project brief’s – what do you add? Please comment and let’s have a discussion….

Mark Norman is a leader, project manager, part time archaeologist and mountain climber. You can read more from Mark on his blog.