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). stakeholdermap.com
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.
Enter the name of your project, the project sponsor and the project manager. Enter forecasted start date and completion date of the project
For each change to the Project Brief keep a record of the version number, status, date, author and the details of the change.
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 – 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.
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……."
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.
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 |
|---|
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) .
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.
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.
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.
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.