QUESTION ONE [40] Read the following excerpt and answer the questions that follow: Understanding Quality in the Project Management Domain What is quality? Customers know it when they see it. Suppliers promise that their goods and services embody it. Both views are often missing a clear, up-front definition of what quality is, and this leads to confusion and frustration when trying to determine just how to deliver it. Project managers probably feel this most acutely. A customer may demand quality and an organization may promise to deliver quality, but a project manager is the one who has to do it. Failure can have devastating immediate and long-term consequences for both the project manager and the project organisation. Given its importance to project outcomes, quality ought to be a problem long ago solved. It is not. Projects continue to be plagued by imprecise quality goals and arcane quality methods most suited for a shop floor, all of this condemning the project to less-than-satisfactory results or worse. There is a better way. From a product manufacturing or service delivery point of view, quality is, to a great degree, a problem solved. Quality tools and techniques have been developed and refined over the past 100 years to the level that they are now a matter of science, not art. Applying these proven ways to project management should be a simple matter of transference, but that is the problem. Projects come in many stripes and colours. A project undertaken by a national professional association to create a new technical manual has little relation to the codified quality tools of manufacturing, except in the final steps of producing the book itself, and that task is usually contracted to a source outside the project team. The key to project quality lies in making a more effective, meaningful transfer of proven quality methods to a general project management domain. The first step is to answer the question What is quality? Several definitions of quality already exist. In the now obsolete 3rd edition of his groundbreaking Quality Control Handbook, quality pioneer Joseph M. Juran defined quality as fitness for use. In this view, customers defined the use for the products (goods or services) that they purchased. It was up to the organisation that produced the products to understand the needs of its customers and to design products that are fit for use. In Jurans Quality Handbook, 7th edition, a revised definition appears. Quality is now fit for purpose. This new view is intended to be broader in scope and more universal in applicability, especially for service organisations that have risen to a larger role in the world economy since the appearance of the original definition. Juran recognised the shortcomings of such a brief definition. He emphasised that the definition of quality includes two components that are critical to its management. Quality includes features that meet customer needs. These features should, among other things, increase customer satisfaction, prevail over the competition, and enhance product sales. Because more or better features add to design, it is reasonable to say that higher quality costs more. Quality also includes freedom from failures. These failures may be errors during production that require rework (doing something over again) or failures in the field after purchase that may result in warranty claims, customer dissatisfaction, or dire consequences to the user. Because an absence of failures means an absence of associated costs, it is reasonable to say that higher quality costs less. Juran also made a distinction between Big Q and Little Q. The concept of Big Q is a more recent development, arising in the 1980s, and is more systems-wide in its approach. It takes a broader view of quality that encompasses the goals of the enterprise and all its products. It is usually embraced by quality managers and senior managers within the organisation. Little Q is more limited in scope, often focused on individual products or customers. This view is usually embraced by those in technical or staff functions. The PMBOK Guide defines quality as the degree to which a set of inherent characteristics fulfil requirements. This definition matches that of ISO 9000:2005, published by the International Organization for Standardisation.3 The ISO 9000-series standards are a group of international consensus standards that address quality management. ISO 9000:2005 is a brief introductory standard that covers fundamentals and vocabulary. This definition is most complete because it is so general. The set of inherent characteristics may be of a product, processes, or system. The requirements may be those of customers or stakeholders, an important group that is ignored at great peril to the success of the project. In the current standard, ISO 9000:2015, the definition of quality includes the phrase inherent characteristics of an object The definition of object as anything perceivable or conceivable is so broad that it might include almost anything. The Standard for Project Management clarifies this scope issue by adding characteristics of a product, service, or result to the definition of quality in the PMBOK Guide. One important aspect of quality is that quality is counterentropic; it is not the natural order of things. Entropy, from the Second Law of Thermodynamics, says that things naturally move from a state of organisation to a state of disorganisation. Drop a handful of mixed coins on the floor and the result is not an array lined up in rows by type. The result is a bunch of coins spread randomly across the floor. So it is with quality. However, it is defined in that quality is not a naturally occurring event. It is a result of hard, deliberate work that begins with planning, includes consideration of contributing elements, applies disciplined processes and tools, and never, ever ends. Achieving quality in project implementation is not a matter of luck or coincidence; it is a matter of management. The project triple constraint includes time, cost, and scope. All three elements are of equal importance to project success and to the project manager. Project managers typically try to balance the three when meeting project objectives, but they may make trade-offs among the three during project implementation in order to meet objectives and satisfy customers. Quality is a fourth among equals. It may be most closely associated with scope because scope is based on customer requirements and quality is closely associated with customer requirements. This linkage addresses quality of the product of the project. There is another important quality consideration: quality of the project itself. Quality processes, attuned to the scope specifications, will ensure a quality product. Quality processes that maintain cost and schedule constraints will ensure a quality project. Some recent project management literature suggests that quality is part of a quadruple constraint consisting of time, cost, scope, and quality. This approach is wrong-headed for one simple reason: Project managers routinely make trade-offs among the triple constraint to meet project objectives. A project manager should never, never, ever trade off quality during project implementation. Crosbys statement that quality is free is good in theory. In practice, quality does have costs, even if those costs are subsequently outweighed by benefits. The sources of cost of quality are three: failure, prevention, and appraisal. The benefits of quality in project performance are many. Adapted from Rose KH (2022) Project Quality Management Why, What and How. 3rd edition. J. Ross Publishing Questions:

1.1 With reference to the excerpt above, provide a definition of project quality management. (5)

1.2 Evaluate the following statement: Achieving quality in project implementation is not a matter of luck or coincidence; it is a matter of management. (10)

1.3 Quality is a fourth among equals. Explain this statement in the context of quality and the triple constraint. (5)

1.4 Discuss the cost of quality. (10)

1.5 Discuss the benefits of quality in relation to project performance. (10)