Project Brief Template | Word Template FREE Download

The Project Brief is a key document in the Project Lifecycle. It provides a description of what the project will do and is a refined and extended version of the Project Mandate. It forms the basis of the Project Initiation Document (PID)
To get a head start on your project download this FREE Project Brief Template. With this template you can make sure you capture everything you need for a successful project!
This is a FREE Project Brief Template in Word and PDF. The template is fully editable with Word and can be converted or changed to suit your project requirements.

See what is in the Template! Check out the Contents complete with Hints and Tips on how to use.

The Project Brief

Check out the contents below or Grab the template now!

The contents of the Project Brief Template


Field Description and Tips to Complete


Project/Program Details

Enter the name of your project, the project sponsor and the project manager. Enter forecasted start date and completion date of the project

Document Details

For each change to the Project Brief keep a record of the version number, status, date, author and the details of the change.

Purpose and overview of the Project Brief

Explain the purpose of this project brief. You can use the boilerplate text below:

This is the Project Brief for [project name], it gives the direction and scope of the project and forms the contract between the Project Management Team and the project board. Any changes that are made in the Project Brief will need to be referred back to the Project Board.

Background to the proposed work

Background – describe the potential change, idea, and problem. Where it fits into the wider business context. Why it should be done now and the implications of not doing it.

Describe the potential change, idea or problem and the circumstances, decisions, previous work that has lead to this PID being produced. This should make it clear:
  • what is the overall purpose of this project?
  • what previous actions/decisions lead to the current position?
  • why it needs to be done?
  • why it should be done now?
  • what the end result of this project should be?
  • what are the implications are of not doing it?


Objectives should provide a clear definition of what the project must achieve in order to be complete and successful. This section might start "Completion of this project will result in……."

Objectives should be SMART – specific, measurable, achievable, relevant and time-bound. Avoid words like improve, optimise, clarify, help etc. These are too vague to be measurable your result. Project objectives should contribute towards and be consistent with higher level program and/or Business Case objectives.
  • How does the purpose of the project break down into specific objectives?
  • What specific, measurable results are expected at the end of the project?
  • The objectives will be used to measure the completeness and success of the project.


The Scope should make it clear what are the boundaries of the work, what areas of work will be included and what is outside the scope. Where work could or should be divided into phases, a definition of scope for each phase should be given.

The scope may defined in terms of such things as:
  • the boundary between this project and other projects and program – this helps prevent gaps or overlaps in all the work that is necessary to achieve higher-level corporate or program objectives.
  • the work that the project must do, and what it is specifically excluded from doing (you might refer to the list of deliverables if you feel it is complete at this stage).
  • the geographic spread of impact.
  • the coverage in terms the organization(s) and types of role/staff/people/organizations that will be affected by changes arising from the project.
  • The scope should be sufficiently detailed to form a measurable baseline for subsequent change control so that the damaging effects of 'Scope creep' can be minimised.
  • Be specific about what is excluded from this project to avoid any misunderstandings later on.
N.B. there is a risk in using 'exclusion lists' in project documentation particularly contractual documentation. These lists can be mischievously used to claim that an item should be in scope - the "well it isn't on the exclusion list" argument.

If you do use an exclusion list, use it to draw out additional assumptions and to check understanding. Make sure it is very clear that the list is not exhaustive.


Deliverables are the main component parts or outputs of the potential project that have to be produced in order to achieve the project objectives.Deliverables should be tangible and might include things such as reports, consultation documents, submissions, software/IT systems, trained staff, documents, contracts, accommodation and marketing material.

A simple list may suffice, or you might or you may find it useful to use the Work Breakdown Structure to help you identify the main deliverables and the products that form the building blocks needed to produce them.

The table below may be helpful.
Unique ID / WBS ref Deliverable title Deliberable description

Business Benefits

What are the desired benefits to be gained from undertaking this project? Are they tangible/intangible quantifiable/unquantifiable? Who are the beneficiaries? If possible give a value, and suggest a timing for realisation of each benefit.

The information about the desired benefits that will be expected to be achieved and/or enabled by the project.

The benefits should be defined in sufficiently precise and measurable terms for the Project Sponsor /Project Board to decide whether or not it is justified to authorise the project to start and hence to commit project management resources to plan the project in detail.
This should be an explanation of factors that you are assuming to be in place, or to occur in the life of the potential project, that will contribute to a successful outcome. At this stage you might have to make assumptionsabout such things as availability of funds and other resources and about decisions being made in external bodies.


Constraints are things that can't be changed. They are existing conditions that you must take into consideration during the project and may include such things as deadlines, standards, regulatory requirements, a major dependency on another project and resource constraints.


Risks – from your current knowledge explain any areas of uncertainty that represent threats to achievement of the desired outcome, or opportunities that might otherwise be missed. These must be significant enough to help inform the Project Sponsor/ Project Board decision whether or not to approve the project to proceed. A summary of any known threats (and opportunities) facing the project. The detail should of risks and management actions should be held in a Risk Register (see separate risk register template) .

Other Areas of Business Affected

Are there other areas of the organization and/or its customers/partners that could be affected by the outcome of the potential project?

Try to identify ownership of each area and whether they need to be involved right from the start.

Major Dependencies

Dependencies are any events or work that are either dependent on the outcome of this project or that the project will depend on. Read more on task dependencies in project planning.

For each dependency identify ownership and start thinking about how best to manage these during the project. Where there is uncertainty about the likelihood of delivery of an external dependency it should be treated as a risk.

Provide a description of any known dependencies with other projects, program or initiatives which may be internal or external to the parent organization. This may be defined in terms of such things as products/deliverables, resources, decisions, legislation, environmental conditions, economic conditions etc.


A stakeholder is anybody who can affect or is affected by an organization, strategy or project. They can be internal or external and they can be at senior or junior levels.

For larger or more complex projects you may wish to construct a Stakeholder Map by identifying the stakeholders and then analyzing them using the power vs interest matrix or the Stakeholder Salience model.

For guidance on how to identify and analyze stakeholders see Stakeholder Definition and Stakeholder Analysis.

Staff Resources

Resources – give an initial assessment of the amount of resources you need to complete this programme or project. Think about the skills and experience that will be required and when you will need these. This will help identify any gaps once the project is underway and identify the stakeholders you will need to approach to agree resource allocations.

Initial estimates for the staff resources types and amount of effort required to complete the project. This should cover not only specialist skills related to the work to be done but also the project management resources.

Outline Estimates of Time and Cost

Costs – Provide your best estimate of likely cost of completing this project based on how long do you think this work is going to take and the resources (internal and external) that you will use?

These costs will be revalidated as you progress through your project but should be robust enough at this stage to ensure it is worth continuing with the project.

Initial estimates for financial commitments and for timing of key milestones and expenditure to enable the Project Sponsor / Project Board to decide whether the project is viable.
Contains public sector information licensed under the Open Government Licence v3.0.

Notes to help you use the Project Brief Template

This document is a template of a Project Brief for starting a project. The template includes instructions to the author, boilerplate text, and fields that should be replaced with the values specific to the project.
  • Blue italicized text enclosed in square brackets ([text]) provides instructions to the document author, or describes the intent, assumptions and context for content included in this document.
  • Blue italicized text enclosed in angle brackets (<text>) indicates a field that should be replaced with information specific to a particular project.
  • Text and tables in black are provided as boilerplate examples of wording and formats that may be used or modified as appropriate to a specific project. These are offered only as suggestions to assist in developing project documents; they are not mandatory formats.

Follow these Steps to complete the Template

When using this template, the following steps are recommended:
  1. Replace all text enclosed in angle brackets (e.g., [Project Name]) with the value for your project. These angle brackets appear in both the body of the document and in headers and footers.
  2. Change the boilerplate text as appropriate for your project.
  3. To update the Table of Contents, right-click on it and select "Update field" and choose the option - "Update entire table".
  4. Before sharing the first draft of this document, delete the section titled "Notes to the Author" and all the guidance to the author elsewhere in the template document.

Project Brief Template

Word download - Project Brief Template (Word docx)

Word download - Project Brief Template (Word doc)

PDF download - Project Brief Template (PDF)

ODT download - Project Brief Template (OpenDocument Text odt)

Related project templates to download