The Definitive Guide to Project Management: The fast track to getting the job done on time and on budget (2nd Edition)

This chapter introduces the idea of quality, which in a sense is an odd idea because it raises the question of whether quality should be a distinct area within project management, rather than quality pervading all areas of it. The chapter begins by answering this question in terms of general management, and then proceeds to set an approach to quality management for projects. Just like the other chapters in this book that cover the knowledge areas in project management or the process groups, this chapter follows the PMBOK approach to project quality management. The PMBOK approach is consistent with the world's main quality management practices, including:

• ISO 9000^[1] series.

• Iskikawa.

• Deming.

• Juran.

• Crosby.

• Six Sigma.

• Failure Mode and Effect Analysis.

• Voice of the Customer.

• Cost of Quality (COQ).

• Continuous Improvement (CI).

• Total Quality Management (TQM)^[2].

For a summary of the key features of four of these, see Table 8.1. The PMBOK approach is also consistent with the approaches to quality espoused by:

• Def Stan 05-97^[3].

• Review, Learn and Improve (RLI).

• Lean Quality.

• House of quality.

• Quality Value Added (QVA).

• Zero Defects (ZD).

• Baldridge.

• John Boyd/OODA loop.

PMBOK adopts unmodified the ISO definitions for key quality management terms (in recognition of which we use 'ISO says' boxes in this chapter where appropriate, rather than the 'PMI says' boxes). It is not surprising that the list of compatible approaches to quality management is so long, and we have named only a few, because they are all trying to do the same thing. They are worth listing because sometimes as a project manager you may encounter a low-level executive with nominal responsibility for projects or for quality who will try to argue that the approach to quality management that you want to take on your project is incompatible with some mandated standard. One cannot be too sceptical of this type of claim if you encounter this problem, ask to see the evidence and insist on seeing the details of the argument. The authors' experience of quality management, after a slightly sceptical start, is that there is a great amount in the ISO 9000, PMBOK and other approaches to quality management that can add real value to projects and their project managers, if used intelligently.

Quality is an odd thing to manage. Surely the whole point of management is to do a quality job? As someone once said, if a thing is worth doing, it is worth doing well. And real-life pressures and incentives mean that Oscar Wilde's rejoinder, that if a thing is worth doing then it must also be worth doing badly, is not a factor in management. The question is why have a separate angle on management, including project management, just for quality? Should it not be part of everything we do in management, in business, in government? Let us dispose of a completely uninteresting answer to this question quickly, and then give the real and more substantial answers. The uninteresting answer is that we have a separate field of quality management in project management, or in management generally, because there are standards such as ISO 9000 which we want to comply with. This tick-box answer is not a proper answer to the question.

The question is important because if we are to have quality management as a separate part of project management then there will be a substantial cost, if only in your time as a project manager. That cost must be justified if a project manager is to be asked to spend time on quality management, and the PMBOK and other approaches to project management do ask that. There are two kinds of answer to the question, both of which are different sides of the same coin, so to speak. One answer starts with human nature, the other with the problems of complexity. The reader may be concerned that we have not yet defined what quality is. Let us proceed in answering the question using whatever intuitive notion we have of what quality means, and later we will come to a formal definition.

Most people, especially in business, are perfectionists. They naturally want to do a high quality job, other things being equal. It is difficult to maintain one's motivation, sense of purpose and pride in one's work if one deliberately tries to do a bad job. There are, however, a number of reasons why even the most able and energetic person may produce a high quality piece of work. And think who decides what quality is? In project management, as in all business, it is the customer, the organization or person or team for whom the project is being done, not the team or person doing the work, who decides what is to count as a good job, that is, what counts as quality. Some of the reasons why good people working hard to the best of their ability may not produce quality work are as follows:

• The customer's requirements were not understood.

• The customer's requirements were understood but were not possible to achieve.

• The customer's requirements changed.

• All other requirements were met but at much greater cost than was necessary (i.e. the implicit cost requirement was not met).

• The people doing the work lacked the techniques, experience or skills to do the work well.

• The work was done in a way that did not last (i.e. the implicit requirement for persistence was not met).

• The final result met quality expectations, but the way it was done upset or disappointed people.

• Everything worked out with respect to quality, but the people doing the project were physically or mentally injured in the process.

All of these possible causes of quality failures are consistent with people trying to do a good job, and the last one, perhaps in extreme cases killing oneself through the sheer effort to do a good job, arises precisely from trying too hard to do a good job. Is that a quality failure? Yes, the quality of life of the project team is ruined, and as we shall see the scope of quality management includes more than just the quality of the final deliverable.

Having started from a consideration of human nature, we can see from some of the bullet points above how the problem of complexity also affects quality. When a project is complex, for example it has many stakeholders and a deliverable with many features, it may not be clear what constitutes quality. An excessive focus on satisfying one dimension of quality, say ease of use, may compromise another aspect, say flexibility of use. Quality management is a tool which helps to manage this trade-off.

We finish this introduction by considering why quality should be treated as a separate angle on management, including project management. Let us answer this from the point of view of management generally, as the answer translates readily into project management terms. Management (and project management too) is a unified whole. Financial management is part of management, as is managing people and legal and regulatory management, in the following way. A manager cannot make decisions of strategic importance, or decisions about the general direction and management of an organization, exclusively on the basis of financial factors, while ignoring human factors and legal or regulatory issues. All the different aspects of management need to be considered, certainly at senior management levels and usually at middle management levels, and also in project management. By dividing up the large and difficult subject of management into distinct subject areas people, finance, leadership, legal and regulatory, marketing and sales, and so on we are able to make a better job of it. Quality is simply one of the areas within management.

Having set the scene for quality and introduced the notion, let us move to a formal definition of quality within the specific context of project management.