Carrying out a PRINCE2 Quality Check

Carrying out a PRINCE2 quality check

During the creation of a PRINCE2 plan, a product description will be created for each specialist product that will be procured or created during the project.  The creation of the specialist products normally takes place during a delivery stage which is using the Controlling a Stage and Managing Product Delivery PRINCE2 processes.  When the stage plan is authorized at an end stage assessment, so two are the relevant product descriptions, and these are along with the plan are therefore baselined.

Quality checking of these products will occur during the stage after they had been created by the specialist team, and this quality checking determines if they are complete.  A completed product means that it fulfils all of the quality criteria as laid down in the product description.

Directly the stage plan is authorized by the project board which uses the activity Authorize a Stage or Exception Plan, then the project manager authorizes the first work package(s), and each of these contains at least one product description.  The work package is now executed, and for the work package to be completed, each product must have passed its quality criteria and are hence ‘fit for purpose’.

The team manager role is responsible for ensuring that the product creation work along with quality checking is carried out within the work package.  This meets the PRINCE2 Principle of Focus on products. The team manager will give the project manager regular checkpoint reports advising on the progress of the product creation and quality checking.  If any issue or risks arise which would prevent the completion of the products, the such issues or risks are be escalated to the project manager by raising it as an issue. This in and of itself may lead to an off-specification or a request for change being raised.

Products are checked for completion using the PRINCE2 quality review, which is focused solely on determining whether or not the product meets the quality criteria laid down within its product description. PRINCE2 also provides a formal quality review technique which takes the form of a review meeting.  However such reviews take place, they should not be used as a forum for discussing ways to correct or improve the product.  In other words, the review should be a straightforward analytical process of comparing the product to the product description and if appropriate, documenting the errors for correction.  They should not become personal nor to try to appoint any blame to individuals.

The individuals involved in the quality reviews should have a vested interest in achieving successful completion of the product, and in ensuring that it is correct. PRINCE2 assumes a customer/supplier environment, and for that reason the individuals involved may not have the same interests.  PRINCE2 uses the Organization Theme to describe the structure of the project management team. For example the producer of the product and the supplier will be keen to ensure that the product is signed off as completed with no errors.  This interest will be higher still if completion leads to a payment milestone.

Another point to consider in choosing the right method to carry out quality checking, for a small simple project using a simplified project management team for example, and the roles used in this case may simply be one person for the reviewer who then liaise is directly in a follow-up meeting with the individual that created the product.

The individuals involved in the quality review may only have the knowledge skills and experience necessary to determine whether or not the product meets its quality criteria.  It is therefore important that such review meetings should not become a forum for problem-solving, which in itself can lead to the meeting over running its time-frame and potentially causing delays to the completion of the work package or the stage plan. This may lead to the project manager raising an Exception Report as part of PRINCE2 controls and tolerance.

Taking the view from the customer side however, they will have a vested interest in ensuring that the product is complete because obviously they will be using the product, or at the very least relying on the product realizing their benefits.  For this reason, they will also be keen to ensure that the project and its milestones deliver on time.

When the project board along with other members of the project management team, is designed and appointed, it will include the role of project assurance, and those who fill this role must be independent from the project manager and the specialist team for these reasons.  An example of one of the responsibilities of project assurance is to balance the above potentially conflicting interests, and although they do not always needs to take part in the actual quality reviews, then at a minimum (at stage planning time), they should ensure that the right people are involved in such quality reviews, and during the stage, checking that’s such reviews have actually taken place in an appropriate manner.

For this reason, the project manager should work closely with project assurance during the stage planning time for them to be able to advise on suitable reviewers for each quality review based on their knowledge of the project objectives and any lessons learned thus far during the project.  Their independence can be vital particularly if for example, that the specialist team members feel that their work has been unfairly and harshly reviewed.

Remember, that the quality check reviewers should be focussed on identifying defects in the products, not in the work of those who created or procured it.  All those who participate in the review, need to work as a team with a common objective to identify if the product is correct and if not, to identify the rework actions.

Another vital service by project assurance can bring to the project may be two train those who will partake in the quality reviews and ensure that they understand the technique, their role and responsibilities, and that they are properly briefed before carrying out the reviews. Such roles are designed within the PRINCE2 Starting up a project process, and are reviewed during the Managing a Stage Boundary process.

PRINCE2 states that the quality review is a generic technique which could be used within an organization outside of an individual project.  Knowing this is helpful, in that the quality review roles have no specific relationship to the roles within the project management team structure.  However consideration should be given to the project manager or team managers to regularly share the reviews.  The charing of such quality reviews only requires competence in the facilitation and independence of the review process, and as such, ensure that the review is properly undertaken.  Indeed, those who chair such reviews must have neither involvement nor authority within the review itself.  In short, the chair person should have skills in driving the meeting to a clear decision, to remain unbiased, and to be able to summarize the review outcome.

The sequence structure of a PRINCE2 quality review consists of the reviewer preparation, the review meeting agenda, and the review of follow up.  The review meetings must be organized, chaired an concluded with a recommendation of either acceptance of the product or agreed rework, and this is the main responsibility of the individual who chairs the quality review.

When considering rework, it is important to understand the work effort, cost and time needed to correct the error.  In some cases this may be seen as two high when compared to the error itself.  It may be, that when estimating rework, that it would cause tolerance to be exceeded if carried out.  In such a case, the team manager should escalate this to the project manager in the form of an issue, to await their decision.

There is an infinite variety of the different types of product, and therefore the approach, style, and techniques of the quality review will vary greatly.  Where the product is a document for example, then it may be adequate merely to read it, check its content, format, grammar, style, length and so on.

Another example of a quality check may be walkthroughs, demonstrations; trial runs all just a visual inspection.  However such checks are carried out it is vital that the reviewer has a full understanding of the quality criteria and the priority both within the product and within the project.  It is clear that the balance is needed to ensure that the product is ‘fit for purpose’ and a level of pragmatism is needed if the process is not to stall over minor errors.

The first step is called the review preparation and it is here that the product will be reviewed in line with the quality criteria laid down in the associated product description.  As a result of this a question list should be submitted to the chair and the presenter ahead of the review.  This question lists can take the form of a simple check box to indicate if the criteria has been it or not.  There should also be a place on this list for the reviewer to articulate any errors.  In the case of a document, then the question list information could be allocated directly onto the review product itself.  This question list should be sent to the chair and the presenter, who will walk through the list during the review meeting itself.

There are three possible outcomes of the review meeting which must reach a collective decision:

Complete.  This means that the product is fit for purpose.  This means that the product can be signed off and notification of this passed on to the project manager and team manager

Conditionally complete.  The product is fit for purpose subject to the actions.  Once the errors have been corrected the product can then be signed off as completed without a further quality review having to take place.

If for any reason, the outcome of the quality review meeting cannot be agreed, then they should be raised as an issue after the meeting has concluded.

Incomplete.  The product must go around that the quality review cycle one more time.  This means that the errors cannot be corrected with a simple rework, and in addition, such corrective action will bring about a significant change to the product, meaning that the review process will need to start again from the beginning.

Post the meeting, all follow-on actions should be carried out, and for this reason either the project manager or the team manager should be notified immediately so that a plan can be created for the rework.  The work package will detail if any other products are affected by the one being reviewed.  And if this is the case then again, a project issue should be raised.

After the product has successfully passed its quality review, it will normally be handed back to the team manager or the project manager.  Alternatively it may be given those responsible for configuration management (project support).  Depending upon the number of products within a work package, and the logistics between the creators and the project manager, it may be appropriate to wait before all products within a work package are completed before returning to the appropriate individual.

Throughout the quality check the quality register is kept up to date.  This is particularly important so that the actual progress can be recorded in the stage plan.  As at any point within a project, lessons can be added to the lessons log which is normally maintained by the project manager.