Quality is one corner of the cost/time/quality triangle. The customer has to decide where a project's main focus is to be. If you want the product to be cheap, that may have an effect on the quality. If there is a squeeze on cost or time, the easiest solution is to cut quality corners; use materials or work of lesser quality, cut out some inspections or release products known to be of inadequate quality.
A few years ago I examined the computer department of a large company. Its staff had a list of six typical complaints from users:
- The end-product was not what we originally asked for
- The system and the project changed direction without our realising it
- The costs escalated without our realising it
- We were told the system would be delivered late, but only when it was too late to supply extra effort
- We were in the dark during most of the development, and even now we do not really understand how to make the system work
- The programs are not reliable so maintenance costs are higher than expected.
This embarrassing list showed that customers were ignored during most of the project. But all these complaints affect the quality of the product. So why are there so many quality problems?
It is dangerous to assume that the customer will always want a superb quality product that will last for ever.
Two projects I came across took a markedly different line on quality. In one a telecoms company bid for a packet switching system in Australia. It was the favoured supplier and its bid price looked good in relation to its competitors, then the customer realised that most of the system would be deployed across a desert, making it very expensive to fix any faults, so the tender was recalled. When it re-emerged it contained a quality requirement that all components had to have a mean time between failures of three years. This was backed with heavy penalty clauses.
The company's bid had included testing work to a commercial level but it became clear that this would not be enough. The price of its upgraded bid was too high to win the contract.
An oil exploration company asked its IT section to analyse the results of a survey quickly and decide if there was oil to be taken - the exploration contract had to be renewed or it would lose its favoured position. The quality need here was for accuracy of analysis and a fast turn-around. The firm was not worried about the result being user-friendly and the product was to be used once, then thrown away.
Quality thinking starts with the customer's expectations. Both supplier and customer may have standards and, depending on the environment into which the product will be delivered, other standards may also apply. These requirements need to be scaled down to suit the individual project, then built into detailed plans to ensure that quality is built in, who will do this, who will check it and when.
Many of the horror stories we hear are caused by the customer not being involved in quality checking until work is handed over as finished. Suddenly the customer starts finding errors, some of which may go back to a failure by the supplier to implement the specification or a failure by the customer to specify correctly.
Corrections will be expensive, target dates will be missed and there will be disputes, possibly litigious, about who pays for the changes.
Quality problems in projects are also caused by failure to control changes or to keep track of the latest version of products. Change control and version control may be boring but they are essential parts of quality work.
Early precautions guarantee success
- Identify the customer's quality expectations before the project begins
- Identify the standards and tools to be used to meet theses expectations
- Set up change control and version control
- Build the costs of all the quality tools and work into the project plans
- Take the quality expectations down to the level of each product and identify the methods and resources to be used to check the work
- Involve the customer in specifying the quality and checking for its presence
- Check quality all the way through a project - don't wait until the end
Prince2: a practical handbook, by Colin Bentley, is part of the Computer Weekly Professional Series.