PRINCE2 - Starting up a Project (SU) part 5
of the Cabinet Office under delegated authority from the Controller of HMSO.
Preparing a Project Brief (SU4)
Fundamental principles
The Project Board must satisfy itself that the project is viable.
It requires a statement of requirements and expectations to ensure it is based upon consistent and adequate information.
Even if a Project Brief has been supplied via programme management it will need checking to make sure that it is still current.
Context
The external trigger for the project is the Project Mandate.
This sub-process checks its content to see if the information is current and correct and where necessary enhances it into the Project Brief.
This may of course already be supplied by programme management if the project is part of a programme.
It would be checked and modified as necessary. However, any changes must be agreed with programme management who will carry out any impact analysis. The results from this may be entered into the programme and project Risk Logs.
Process description
The objectives are:
- Prepare the formal ‘terms of reference’ for the project
- Establish the customer’s quality expectations
- Establish the 'Acceptance Criteria' [see PRINCE2® Product Description in file ‘Acceptance criteria.doc’ in the product package] for the project
- Ensure there is an outline Business Case based on the information provided in the Project Mandate
The Project Brief needs to include high-level information concerning:
What needs to be done
Why (the benefits to be achieved)
Who will need to be involved in the process
How and When it will be done
The Project Board must decide if there is sufficient grounds to release funds for the initiation stage.
The Product Description is given in file ‘Project brief.doc’ in the product package.
The customer quality expectations will be provided by the customer / user community via Senior User, the Executive and other stakeholders.
This must be known as it will have dramatic impact on cost and time. See the sub-process 'Quality in a Project Environment' for additional details.
Prioritisation should be given to user requirements. Then if the project scope has to be modified later funds can be targeted to those items promising a higher return. The Acceptance Criteria will form part of the ‘terms of reference’ and are given in the Product Description in file‘Acceptance criteria.doc’ in the product package.
The contents of the Project Brief should be discussed with all stakeholders.
The detail in the Project Brief will vary according to the nature of the project but all elements should be considered even if it is decided that a particular element is not needed.
During preparation of the Project Initiation Document and the rest of the project the Business Case will continue to be refined.
The customer quality expectations and Acceptance Criteria will be used in the initiation stage to create the Quality Plan.
It will be good practice to create the Daily Log in this sub-process for the use of the Project Manager throughout the project.
For similar reasons the Risk Log should be created to hold details of the risks, their analysis and any actions.
Responsibilities
The Project Brief is the ultimate responsibility of the Executive.
In practice, the Project Manager and Project Support staff will carry out the majority of the work.
The Executive should review the Business Case and the Risk Log under the role’s Project Assurance responsibilities.
| Management information | Usage | Explanation |
|---|---|---|
| Daily Log | Output | The Project Manager’s informal record of actions, decisions, events and jobs to be done. |
| Risk Log | Output | To record risks, including any noted in the Project Mandate or Project Brief. |
| Project Brief | Output | Submission to the Project Board as part of the justification for initiation. |
| Project Mandate | Input | The external trigger from corporate or programme management containing the reason for the project. |
These are given in tabular form in the file ‘preparing a project brief.doc’ in the product package.
Key criteria
- Does the Project Brief contain all the required information?
- Is the information in the various sections of the Project Brief consistent?
- Is the ‘ownership’ of the project properly defined?
- Is there any potential disagreement on the Project Brief contents with the Project Board members?
- Is the Project Brief suitable for a decision to be made on whether to authorise initiation or not?
- If the project is one of a chain does it conform to any prior projects?
Check the Project Brief informally with the Project Board prior to presenting it formally for approval.
Are there any conflicts of interest within the parties to the project?
For small projects the Project Brief may not be needed as a separate document and may be more useful to just produce the Project Initiation Document. In such a case, this process and the process 'Initiating a Project (IP)‘ could be combined as one.
The Project Brief should be as small and high level as is consistent with the decisions that need to be taken in Authorising Initiation (DP1).
Managing Successful Projects with PRINCE2 - 2005 edition
Managing successful Projects with PRINCE2 – 2009 edition
Directing Projects with PRINCE2.
plus:
The Complete Project Management package.
And much more besides - at a fantastic price.