Professional Scheme
Relevant to Paper 2.1

The Study Guide for Paper 2.1 Information Systems makes explicit reference to a Project Quality Plan: ‘Describe the typical contents of a Project Quality Plan and explain the need for such a plan’.

This article describes the depth of knowledge required by this teaching point. The contents and structure of a Project Quality Plan differ between project management methodologies. For the purpose of the ACCA syllabus, the Project Quality Plan has a wide interpretation, covering most of the initial concerns of the project manager outside the Project Plan itself. The Project Quality Plan is created in tandem with the Project Plan. The Project Plan shows the project deliverables, the allocation of staff and the timescales of the project. The Project Quality Plan describes the framework in which the work will be accomplished.

The Project Quality Plan is one of the key documents produced by the project manager or project management team. It defines all relevant standards and procedures to ensure that work is completed successfully to the required level of quality. The project manager must ensure that all project staff are aware of the existence, purpose and content of the Project Quality Plan and it should be referenced throughout the project. In some instances, external customers (such as the Ministry of Defence) may wish to define standards for the Project Quality Plan and to review and sign it off as part of their contractual procedures.

The possible structure of a Project Quality Plan is presented below. This structure may at first glance look daunting, but it must be stressed that it is an exception document, cross-referencing other standards and policy statements produced by the organisation. The Project Quality Plan will cross-reference the documents where those procedures are defined and document any exceptions or additions to those procedures for this particular project.

Quality Plan Contents
Introduction
The introduction should include a definition of the purpose of a Project Quality Plan and how it fits into the planning and management of a project. It should also indicate whether the plan is part of the contractual requirement and, if so, how this has influenced the content and format of the plan. Some customers may require the Project Quality Plan to adhere to certain defined standards (for example, PRINCE II) and this may mean that the format of the Project Quality Plan usually used within the company has to be amended.

Project Overview
This section contains a general description of the project including the client, the objectives and the major deliverables of the project. In many respects it is a summary of the main points of the Project Initiation Document (PID) and will cross-reference that document or extract its main points. However, unlike the PID, this section of the Project Quality Plan will be updated if changes take place in the project environment; for example, if the original project sponsor leaves and is replaced.

Glossary of Terms
The glossary provides definitions of general terms with particular meanings used in the plan and any terms specific to the project. This enables the reader to correctly interpret the contents of the Project Quality Plan. For example, the word ‘prototype’ may have significant meaning in a particular project and hence this section of the Project Quality Plan may be an appropriate place to unambiguously define this term.

Product Requirement
This is a description of the work to be carried out with a list of timescales, deliverables and project milestones with appropriate references to relevant specifications. The description of the work may include areas such as performance criteria, security requirements, legal constraints and client standards. This section of the Project Quality Plan will extensively cross-reference the Requirements Specification and (where one exists) the legal contract with the client.

Project Organisation
This section details the organisation and management of the project, specifying management roles (with named individuals) and their responsibilities. This might include:

• contact points for technical information within the client organisation;
• required resources and their origin (departments, sub-contractors etc).

It is likely that the definition of the responsibilities of the project management roles are standard, although again significant exceptions may apply on certain projects and these should be highlighted in this section.

Monitoring and reporting procedures
This section is a description of the procedures that will be in place for planning, monitoring and controlling the project. This will cross-reference project standards that define how the plans will be constructed and presented, how progress will be monitored and slippage addressed and the frequency and contents of project reports. These standards will also include agreed support tools (such as Microsoft Project). Exceptions or additions to the normal standards will be documented in the Project Quality Plan. For example, exception reports will be produced fortnightly (rather than monthly) for deliverables on the critical path.

Development Lifecycle
This section will describe the main project phases of systems development, with details of the:

• start criteria for the phase;
• standards, methods and procedures to be used in the phase;
• test, inspection and review procedures for the phase;
• phase completion criteria.

The development lifecycle description is likely to extensively cross-reference the organisation’s development standards. Where the standard methods are not to be used an explanation should be given. For example; Data Flow Diagrams will not be used to model the current operational system because the client perceives that the proposed solution should be radically different to the current system and hence modelling the current system is inadvisable. This section of the Project Quality Plan will also comment on the use of support tools, such as CASE (Computer Aided Software Engineering) tools.

Quality Assurance
Quality Assurance (QA) is concerned with reviewing the project work as it progresses. It aims to discover errors as early in the project lifecycle as possible. The frequency of reviews will depend upon the type and quantity of work. For example, it may be appropriate to review a number of small, interrelated deliverables (perhaps produced by different staff) at a single meeting.

Reviews may be:

• self-checking;
• peer-to-peer review;
• subject to formal project review;
• subject to formal external review.

It is likely that standard Quality Assurance procedures have been defined within the organisation. This section will reference the documents where those procedures are described, with any significant exceptions noted. For example; “peer-to-peer reviews will replace formal inspection methods in the Lotus Notes development team, because of lack of resources available to sensibly undertake the formal reviews”.

Testing
The dynamic testing phases (unit testing, system testing, user acceptance testing etc) will be defined in this section. If the company has a defined test methodology then appropriate documents will be cross-referenced in this section. If the company do not have such documents then the appropriate test strategy may be defined in this section of the Project Quality Plan.

Quality Documentation
It is important that the results of quality assurance and testing are documented so that quality management can be verified as rigorous and avoid inadvertent repetition. A simple process may be used, where for each quality check a form is completed showing:

• review date;
• deliverable(s) reviewed or tested;
• reviewer(s);
• description of errors found;
• action point(s) for error correction;
• severity of error.

These quality management requirements are usually defined in organisational standards, often with specific references to where documentation should be stored. The Project Quality Plan will cross-reference these standards, with variations and additions documented. For example; the project will use TESTDIRECTOR software product to log all static reviews.

Procurement
The project may require certain products (for example, hardware) to be purchased, rather than developed. A process must be defined for effective procurement. This may again be project specific or it may extensively reference current organisational procedures for purchasing. This process will include:

• the purchasing policy;
• the system for supplier selection and evaluation;
• the goods inspection method(s).

Sub-Contractors
The project may require that certain parts of the systems development are sub-contracted to a separate organisation. For example, parts of the programming may be sub-contracted to software houses in India. This section will describe:

• details of sub-contracts;
• the system for sub-contractor selection and evaluation;
• how work will be distributed to sub-contractors;
• how sub-contract work is monitored and quality checked;
• acceptance procedures for work produced by the sub-contractor.

Non-conformance
The project may have to purchase goods and services that do not conform to the quality requirements of the project. This section will describe how they will be dealt with. This is important where suppliers cannot adhere to the overall certification standards required of the project. For example, they may not have the required ISO certification. Non-conformance has to be recognised and possibly reflected in the contract with both the customer and the sub-contractor / supplier.

Change Management
Describes the procedures to document and control changes to the scope of the project. This will include the system for logging change requests, the method of impact analysis and gaining and documenting the authorisation / approval to apply the change. It is very likely that the organisation has standards for change management and so this section may just have an appropriate cross-reference to the standard process.

Configuration Management
Configuration management concerns the control of the product at all stages of development and production. It is mainly concerned with controlling the components and versions of the system during production and maintenance. During the development of the system it is not uncommon for multiple versions of the system to exist. If changes are made to the system then it is important that changes are made to the correct version of the software and to all copies of that version. Configuration management software may be used and specified in the Project Quality Plan to help ensure proper configuration management.

Risk management
Risk management is concerned with identifying potential problems and eliminating or reducing the damage the realisation of those risks would cause. Failure to adequately manage risks will threaten the success of the project.

Risk management is the responsibility of the Project Manager because this is the person responsible for the success of the project. A well-planned approach to risk control allows the Project Manager to concentrate resources in those areas where risk is high and reduce risks to acceptable limits.

Risk assessment and management must be conducted at the start of the project and also throughout the project lifecycle to ensure that risks are understood and controlled. It is usually impossible to eliminate all risk but it is possible to manage projects in a way that recognises the existence of risks and prepares, in advance, methods of dealing with them if they occur.

The risk management process requires that each risk is assessed and measures formulated to prevent it (avoidance actions) or minimise its effect should it occur (amelioration actions). Both need to be considered because avoidance measures may fail. (See Example 1).

As a project proceeds, the nature of risk changes. Old risks disappear and new ones appear. Consequently, risk management is a continuous process and so there needs to be a procedure to regularly review and reassess risks. Furthermore, it is essential that all risks are owned by someone who has sufficient authority and resources to do something about the risk. In some instances risks are assigned at too low a level (the owner understands the risk but cannot do anything about it) or too high a level. In this instance the owner has the resources and authority to do something about the risk but does not understand the risk or give its solution sufficient priority.

It is likely that standards exist for risk management in the organisation. These will be applied in the Project Quality Plan or perhaps in a separate document, which is referenced by the Project Quality Plan.

Delivery
This section specifies the arrangements for handling, delivering and installing the deliverables defined in the Product Requirement section of the Project Quality Plan. Any special needs, such as security, access to buildings, transport and insurance should be included in this section. It is possible that a standard checklist exists for this section, defined to help project managers identify the issues they must consider in delivering the product. Appropriate parts of this checklist will be used in this section.

Summary
This article defines the level of knowledge required by a candidate for the 2.1 examination. In many organisations the Project Quality Plan is an exception document, ensuring that the project managers have considered these aspects of the project. In other instances, the absence of such standard procedures means that many requirements have to be defined in the Project Quality Plan itself.

Steve Skidmore is Examiner for Paper 2.1