Quality Management in Project Management and Agile practices is one of the most important topics in every product development process. Quality management in classical Waterfall project management practices and in Agile practices have very similar approaches.
The key quality concern for IT projects
The key quality concern for IT projects is providing customers with the systems they need and which meet their requirements at a price they can afford. In order to achieve this, quality needs to be built into a product.
It cannot be added to a product after it has been created – except with great difficulty and cost. It is like trying to alter the foundations of a building once it is complete. To build in quality requires a commitment from all parties to the project, from the project sponsor through all the levels of management to the technical staff, customers, users and the clerical support staff.
Philip Crosby’s seminal book on quality opened: Quality is free. It’s not a gift, but it is free. What costs money are the unquality things – all the actions that involve not doing the job right in the first place.
(Philip B. Crosby, Quality is Free, New York: Mentor, 1980)
Crosby was not arguing that increasing the quality of a product did not cost money; rather, that the costs of remedying lapses in quality would be even greater. There is a relationship between quality, cost and time. A higher level of quality can increase the duration of a project and/or its cost. This is called the cost of conformance. But the more effort goes into quality, the less expenditure is needed on correcting and compensating for faults at the end of the project – the cost of non-conformance.
The project manager balances types of cost
The project manager must balance the two types of cost. It is important to distinguish between quality control and quality assurance. Quality control is concerned with the practical activities that check the quality of a deliverable or intermediate product, for example that manufactured light bulbs actually work. Assurance activities do not check product quality directly but instead check that the required steps that establish product quality are in place and have been carried out. This might check, for example, that process standards belonging to the activity have been followed, such as a checking process for the purity of raw materials used in a process. This could involve examining evidence such as testing plans and sign-off documents. Section 5.4 explores this in more detail.
DEFINITIONS OF QUALITY
A definition of quality is a degree or level of excellence, as in the phrase ‘high-quality goods’. This definition is subjective: for example, when comparing cars, people argue about the quality of different makes.
Another definition is conformance to standard. Within a project process there will be certain standards to which developers are expected to conform. These standards help reassure the project’s clients that they will get value for money for the project’s products. However, the generally accepted definition which should apply to all projects is that the deliverables should be ‘fit for purpose’. Again referring to cars: if you need to get to work on time, a Rolls-Royce may not be the best vehicle to navigate through heavy traffic – a scooter might be more effective. The original international standard on quality, ISO 8402:1994, formally defined quality as ‘the totality of features and characteristics of a product or service which bear on its ability to satisfy stated or implied needs’.
One aspect of this ‘fit for purpose’ definition, reliability, shows how the concept applies. If the Water Holiday Company’s booking system is out of action for a time, it would be annoying but not life-threatening. However, if the control systems in an aircraft in flight fail, that would be disastrous. Hence, the effort devoted to making sure that the aircraft system does not fail would be greater than that required for the Water Holiday Company integration project. The required quality varies depending on the type of system under development and the money the customer is prepared to pay.
Those responsible technically for a project must advise the customer on the benefits of a well-engineered system, but the person paying usually calls the tune. However, suppliers also have a professional and legal commitment to the general public to ensure that the systems they produce are safe. The possibility of an aircraft crashing in an urban area makes us all stakeholders in aircraft safety.
As IT systems become more complex, it is impossible to ensure that they will never fail. Thus, it is important to examine the ways in which the systems under development will behave in the event of various types of failure.
This will directly influence the development process and how quality is measured. For example, a control system for a nuclear power plant will be designed to ‘fail safe’ – that is, in the event of a systems failure it will revert to a safe state, for instance by closing down. Obviously, such a requirement must be specified in the quality criteria for the system.
Where something is inherently dangerous, as in this example of the nuclear power plant, the developers would have a duty of care, not just to the project sponsor, but to the world at large. It is also likely that governments, either individually or collectively, will enact legal requirements in such circumstances with which there must be compliance.
The testing of deliverables for required qualities needs the deliverable to actually exist. This is rather late in the development life cycle. It is therefore useful to identify process standards governing how products are created that can be applied at an earlier stage.
QUALITY CHARACTERISTICS IN WATERFALL PROJECT MANAGEMENT AND AGILE DEVELOPMENT
The definition of ‘fitness for purpose’ needs elaborating so that it can be applied practically. Another international standard, SQuaRE (standing for Software Quality Requirements and Evaluation), is documented in the ISO 25000 series of standards and defines a set of standard characteristics by which software quality can be measured. (This has replaced a previous version, ISO 9126.)
It specifies the following high-level quality characteristics:
Functional suitability: Does the system as delivered meet the functional requirements of the user? Meeting user expectations is more than just meeting a specification.
Performance efficiency: For example, how fast does the system execute functions? What hardware resources does it need? How many users can access the system at one time?
Compatibility: Can the new system operate with existing systems? In particular, can it share information with other applications?• Usability: Is the system straightforward to use? How much training is required for someone to use it?
Reliability: How often does the system break down? How long does it take to put right? In general, software that has been in use by a large number of people over a long period of time is likely to be reliable. This is because over time most of the faults will have been detected and corrected. Hence the use of the term ‘software maturity’.
Maintainability: Can this software application be modified easily and without introducing unexpected errors?
Portability: how easy is it to move the software from the particular platform on which it was developed to another environment?
The standard itself goes into much more detail for each heading. The top-level qualities are broken into sub-qualities that contribute to the higher-level quality.
Not all qualities are relevant for all projects and project managers need to select those useful for their projects. For example, in the Water Holiday Company booking system, response time in answering queries about the availability of boats is an important part of usability. For the application, engineering measurements have to be mapped to values on a scale reflecting user satisfaction – for example, a response time under five seconds might correspond to ‘acceptable’. Agile project management practices require the same effort and activities.
QUALITY CRITERIA IN PROJECT MANAGEMENT
The level of product quality required has to be specified at the beginning, before the product is developed. In Chapter 2, the concept of a product definition or description was introduced. Each product definition included a section headed quality criteria. These criteria enable checks that a product is fit for its purpose in the final deliverable, or in the creation of other products, by seeing whether it meets the quality criteria specified.
The product definition refers to types of product, not specific instances. For example, for a software module, processing test data correctly could be a quality criterion, but the actual test data will be based on the particular module’s specification. Product definitions are produced at the start of projects and specifications will elaborate and extend the initial criteria. Read more about what is project management in the Brighton’s website to understand all other quality management activities and project management phases.
Effective quality criteria must be specific, measurable and achievable.
As an example, the aircraft control software could have a specific requirement that the product must never fail. It is measurable by running the product continuously until it fails. Unfortunately, it can only be demonstrated that the requirement has not been met.
We can never prove that it will not fail at some point in the future. Hence the ‘never’ requirement is not achievable. We can, however, provide an estimate of the probability of failure which will get smaller as testing intensifies. As noted with the nuclear power station, we can also plan for the possibility of failure, for example, by allowing a reversion to manual control.
Quality Management Activity
Refer back to the discussion about product definitions.
Draw up quality criteria that can be used to assess a product definition (not the product it defines). Add any other headings that you consider should be standard for all product definitions/descriptions. Specify how the criteria can be measured.