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.
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.
The objectives are:
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.
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.
|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.
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).