These will exist before any development, product creation or planning takes place.
They must satisfy a need for basic information on the product:
This is part of the Planning (PL) process.
It will define the product, standards used in its creation and the methods used in checking the quality criteria to ensure that it is fit for purpose.
This information is essential for the product creator and as a checklist in assessing the product quality.
Users of the product should be involved in the writing of the Product Descriptions and in particular the quality criteria.
These should be produced, at least in draft form, once the products have been identified through the Product Breakdown Structure.
There is a complete list of Product Description outlines in the product package.
Each Product Description must be approved and the Project Board will approve the major ones.
These and others may be approved by any Project Assurance function set up by the Project Board.
It will be up to the Project Board to decide which products warrant a Product Description.
In the case of Work Packages the relevant Product Descriptions will form part of the required information.
This will be agreed by the Project Manager and Team Manager as part of the control of suppliers during the process Authorising Work Package (CS1).
The Work Package is authorised by the Project Manager and triggers an individual or group to carry out a task(s).
It is agreed with the Team Manager.
It will contains:
This system of authorisation is particularly useful for contractors and sub-contractors.
Providing the Work Package is described in the process Authorising Work Package (CS1).
The receiving of the Work Package is described in the process Accepting a Work Package (MP1).
There are many quality control methods that can be used depending on the nature of the project and its products. PRINCE2® includes a generic process called a quality review, which, although focussing on documents (including those created by specialists) can be applied to any product.
The aim of the review is to check the product for errors in a planned, independent, controlled and documented manner as part of a team process.
Filed documentation will provide a record that the product was inspected, and errors themselves checked after correction.
The Product Description would identify the quality review as the method of product checking.
Hence, the quality review would form part of the Work Package and any details would be entered into the Quality Log.
This is a record of all the planned and implemented quality checks.
It is created as part of the process Planning Quality (IPI).
The Project Manager will make initial entries as part of Planning a Stage (SB1).
The name of the chairperson of each quality review will be entered in the Quality Log.
The Team Manager may add other reviewers as part of Accepting a Work Package (MP1).
In addition, Project Assurance may add others so that all interested parties are covered.
The Team Manager will ensure that all necessary entries are made as part of the process Executing a Work Package (MP2).
This will be checked as part of Assessing Progress (CS2) and reviewed as part of Reviewing Stage Status (CS5).
A full Product Description can be found in file ‘Quality log.doc’ in the product package.
For project control you must have change control.
Deviation from specification has many sources:
There needs to be a mechanism for raising questions, problems, suggestions and concerns.
These must also be controlled via the Project Issue procedure which will raise and log them.
Such procedures ensure that nothing is carried out without the knowledge of the appropriate level of management.
The process will record all comments, feedback and any actions undertaken.
A Team Manager would raise any Project Issues with the Project Manager.
This will contain all identified risks, their analysis, countermeasures and status.
These will be reviewed at the end of each stage as a minimum.
They will also be reviewed as part of the assessment of each stage.
[see, the management of risk in project management is covered in much more detail in 'The Complete Risk Management package‘].
This is a time driven control examining the status of work carried out.
The frequency will be indicated in the Work Package (this will depend on the level of control required) and can be formal or informal involving the people doing the work.
These will check progress against the plan.
The information is recorded as a Checkpoint Report for presentation to the Project Manager in a formal or informal manner.
The Product Description is given in file ‘Checkpoint report.doc’ in the product package.
Re-planning will be required for most project and just how you much effort you put into the exercise will need consideration.
The Project Manager will not want to re-plan for every minor change that may correct itself any.
Re-planning could be too early or too frequent with no added benefit.
Many Project Managers would use their judgements concentrating on the 'critical path' perhaps.
The re-planning would normally occur at a stage boundary when exceptions arise.
If the plan modifications do not need Project Board approval the Project Manager would deal with them as part of Taking Corrective Action (CS7).
This is a stage progress report from the Project Manager to the Project Board.
It would comprise input from the Checkpoint Report.
The frequency and content of the Highlight Report would be set by the Project Board.
Frequency, which may vary according to the stage, may be defined in the Project Initiation Report.
It would normally comprise:
The Project Board may prefer a Product Checklist providing status and revised dates.
The Highlight Report allows the Project Board to manage the ‘exceptions’ as they will be aware of any stage tolerances that exist.
The Project Board may request that the Highlight Reports are sent to others and would be documented in the Communication Plan.
Those with Project Assurance responsibilities may wish to see the Highlight Reports before the Project Board review them.
As the Highlight Report can raise concerns within areas under the control of a Project Board member it will encourage a quick resolution to avoid any embarrassment.
The Product Description is given in the file ‘Highlight report.doc’ in the product package.