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 Agile methods have very similar approaches.
Get a FREE Trial for the BVOP Certified Project Manager Online Exam
Table of Contents
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 is the low-quality outcomes – 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 standards. 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 system’s 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 products, 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 on 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.
Example of basic Quality Management plan for creating a new product
We present an example and basic Quality Management plan, including only basic topics. In the example, the quality concerns an innovative product machine with an operating system
Machine
Load capacity up to 30 kg
Volume up to 50 liters
Maximum noise up to 25 dB
The material of the outer part aluminum or stronger, but just as light
Color – at the customer’s choice
Minimum 5-year warranty
AAA efficiency class
Hardware
Power supply, motherboard, processor, RAM, and internal memory, which are massive and at the same time high quality. They can be similar to a smartphone.
Touch screen with dimensions 30×10 cm
The hardware warranty is the same as that of the machine body
Ports for connection to other devices
Audible alarm
Software
Known operating system
Be easy to use for people of all ages
Possibility to install additional software
Ability to connect to other devices
Quality management
Machine quality management
Engineering team (professionals with experience in the field)
Non-professional team – to take on the role of the end-user.
Quality inspection
Through technological experiments
By basic and more complex testing of functionality and materials
Example comparison with other products, heating of materials, testing of their strength, noise measurement, and others.
Low-quality scenarios:
Feedback from the manufacturers of the part
Opportunity to return to development
Return under warranty
Quality management of hardware development
A team of computer hardware specialists
A team of electrical engineers
Quality inspection
Tests on the proper functioning of each component
Tests for the compatibility of the hardware with the vibrations from the machine body
Electrical tests
Make sure that no part of the hardware gets wet
Low-quality scenarios:
Opportunity to return to development
Providing a reserve budget for additional funding for development
Communicating problems to third parties involved and providing time to clear up problems.
Quality management of software development
The development team must conduct basic initial tests
The QA team must conduct secondary tests
Tests by a non-professional team to take on the role of end-user (eg marketing department).
Quality inspection
Preparation of quality scenarios
Preparation of automation in quality control
Timely cleaning of problems
Customer Acceptance Test
Low-quality scenarios:
Providing a reserve budget for additional funding for development
Initially given periods for troubleshooting
Prioritization of defects by development teams
Great topic. I would like to ask if we can accept Usability Testing practices as part of QA and agile quality management in general. Little is said about user tests and usability. It seems that many teams and companies do not practice deep UX. I don’t know if it’s because of a lack of competencies or just a lack of resources. I will still be happy for any opinion. I have to write a dissertation on consumer tests in Agile teams and I would appreciate professional views.
Agile teams can learn a lot from the Waterfall approach. Each phase is clearly defined. Also, the PM sets goals and descriptions for every move. If you have a full Quality Management plan and a professional QA/QC team, you are going to succeed.
Waterfall is a traditional approach. PMP for example, created by the PMI provides perfect processes and life cycle to successfully closing your agreements.
Also, Scrum teams lack clear processes. They follow the Scrum framework but they miss the QC rules. The Scrum Master and Product Owner often don’t know the QC rules. Also, they don’t have enough knowledge. The main reason for this is that SM and PO often come from a Software Development background. They don’t get the QC and QA topics seriously.
Colleagues, I strongly recommend that project managers discuss these topics in advance with their line manager. Any change or creation of a new one in the practice of an organization should first be discussed with the line manager. The idea of these quality control practices should be guided by the structure, policies, procedures, and sharing of all information to all units.
The development itself is based on information received about successful or bad past practices in the company. Other representatives of different units and departments could be involved in the creation, who could offer valuable guidelines with examples from the respective units.
And remember, Agile doesn’t mean we can just do whatever we want.
The quality management plan is related to the quality strategy, affecting trade policy, supplier relationships, costs, efficiency. Let’s add that the personnel strategy of the organization has to do with the way of planning quality management. Quality planning and management are among the main activities in the overall quality management system. It is known that even if there is no Quality Management System, the organization must draw up and implement a quality plan (ISO-10005 guides such a plan). Quality planning and management involve the preparation, review, acceptance, partial or major changes to the quality plan.
Maintaining a quality standard requires the need for specific, clear goals for those involved. The quality management plan (and its control) guarantees these objectives and may be part of a contract (agreement) including standards for the implementation of the project work. Aspects should be formulated that highlight how, why, when (and by whom) the quality management process is monitored. The applicable standards section may contain references to international standards (ISO) or recommendations for good practice.