THE QUALITY PATH

Part of the PRINCE2 quality philosophy is that quality is built into every phase of a product’s specification and development and is not left to a check before final delivery.

Quality

7.3.1 Customer’s quality expectations

The customer’s quality expectations should be made clear in the project mandate at the very outset of the project. If not sufficiently clear, the Project Manager should clarify the expectations when preparing the Project Product Description (during the Starting up a Project process – see chapter 10). The customer’s quality expectations are often expressed in terms that are too broad to be measurable.

TABLE 7.1

Step Product Process or

technique

Ascertain the customer’s Project mandate or Starting up a Project. quality expectations Project Brief

Document the customer’s Project Product Starting up a Project. quality expectations and Description

acceptance criteria

Write a Quality Management Project Initiation Initiating a Project.

Strategy Documentation

Write a stage Quality Plan Stage Plan Managing a Stage Boundary. Record planned quality Quality Register Managing a Stage activities Boundary. Define an individual product’s Product Description Product-based

quality criteria Planning.

Explain the techniques, Work Package Controlling a Stage. interfaces, constraints and

configuration management requirements for each piece of work

Report back on the quality Quality Register Managing product

work performed delivery.

Check that quality work is Quality Register Controlling a Stage. being done correctly

Control changes Issue Register Change. Keep track of changes to Configuration Item Configuration

Types of quality expectation will vary according to the type of final product. Suggestions are:

• Major functions; • Appearance;

• Personnel level required to use/operate the product; • Performance levels;

• Capacity; • Accuracy; • Availability;

• Reliability (mean/maximum time to repair; mean time between failures);

• Running costs; • Security; • Ease of use; • Timings.

Any thoughts or actions about quality in a project must start by finding out what the customer’s quality expectations are. It is dangerous to assume that the customer will always want a superb quality product that will last forever. Have a look at the products in your local cut-price store and you will see what I mean. Let me quote you two different examples of customer quality thinking from projects in my past.

Example 1

A telecommunications company had bid for a packet switching system in Australia. They had been told they were the favoured supplier and their bid price looked good in relation to their competitors. Suddenly a bright young man employed by the Australian customer looked at the geography of the country and said to his bosses “Most of this system is going to be across the deserted middle of the country. It’s going to be very expensive to fix any faults out there. Have we specified a high enough quality?” So the tender was recalled and when it re-emerged it contained a quality requirement that said all components (hardware and software) supplied had to have a mean time between failure of three years. This was backed up by heavy penalty clauses in the

event of failure. The bidding telecommunications company looked at its original bid, which had included testing work ‘to a commercial level’ and realized that this was not enough. So lots more ‘testing to destruction’ was added to the price, plus back- up equipment to take over in case of failure, and so on. The price of their bid became so high that they lost the contract (but probably saved themselves money in the long run).

Example 2

The exploration arm of an oil company had a meeting with the data processing section to discuss the results of a seismic survey carried out in the mountains of a South American country. They had a very short time in which to analyse the results and decide if there were oil or gas reservoirs there. Their exploration contract had to be renewed or they would lose their favoured position. Their first quality need was for accuracy of analysis and, beyond that, they needed a fast turn around. They weren’t worried about the result layout being ‘user-friendly’. The product was to be used once and then thrown away.

There are big differences in the approaches to quality needed by these two projects.

7.3.2 Acceptance criteria

These turn the customer’s quality expectations into measurable terms. ‘Of good quality’ may sound fine as an expectation, but how can it be measured?

A project’s acceptance criteria are a set of measurable attributes of the final product. The PRINCE2 concept is that the acceptance criteria must be met before the user accepts the final product. However, some acceptance criteria cannot be measured until the final product has been operational for some time. Such criteria must be added to the Benefits Review Plan.

Acceptance criteria may be split into ‘time zones’. Some must be fully met before the project can be closed, but for others, such as perform - ance, there may be a series of improving targets that must be met after periods of operational use.

Acceptance criteria should also be prioritized in case there comes a time when one criterion can only be fully met at the expense of another one. For example, delivery on time versus having a product that is 100 per cent complete.

Expectations of performance, reliability, flexibility, maintainability and capability can all be expressed in measurable terms.

Acceptance Criteria must be suitable for the product, such as: • Reference to meeting the customer’s quality expectations; • Target dates; • Major functions; • Capacity; • Appearance; • Availability; • Development cost; • Running costs; • Maintenance; • Ease of use; • Timings;

• Personnel level required to use/operate the product.