

Paperback(New Edition)
-
SHIP THIS ITEMIn stock. Ships in 6-10 days.PICK UP IN STORE
Your local store may have stock of this item.
Available within 2 business hours
Related collections and offers
Overview
Product Details
ISBN-13: | 9781604271027 |
---|---|
Publisher: | Ross, J. Publishing, Incorporated |
Publication date: | 05/01/2014 |
Edition description: | New Edition |
Pages: | 248 |
Product dimensions: | 5.90(w) x 8.90(h) x 0.60(d) |
About the Author
Read an Excerpt
CHAPTER 1
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 organization.
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 colors. 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.
Definition of Quality
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?"
Exercise 1 — Consider the question "What is quality?" for a few moments. Take time to do this seriously. Put this book down, get out a blank sheet of paper, and think about the question in depth. What does quality mean to you? What might it mean to others? How do you describe quality to others? How do you know quality when you see it? What are quality's component elements? Make a few notes, then continue reading.
The results of this brief exercise probably vary among individuals. Some central themes may be common to all.
* Products — In some way, quality is associated with products. This may be the most obvious linkage. We define quality by our view of the features or attributes of some particular product: an automobile, an article of clothing, an electronic device, and so on. This view can lead us with confidence to the destructive "I'll know it when I see it" definition of quality.
* Defects — The idea of defects in a product is closely related to the view of products themselves. The perception of product quality may arise from favorable features, such as an automobile that always starts on the first attempt, or is comfortable on long trips, or exhibits efficient fuel consumption. Defects are a bit different. We expect quality products to be free of defects. When we purchase a car, the upholstery should not be ripped or soiled, all the indicator lights on the dashboard should function properly, and there should be no cracked mirrors or light covers.
* Processes — Now things get a little more obscure. If we manufacture a product, we probably care very much about processes. To the users of our product, the matter of processes tends to be rather transparent. Users focus more on the product and how it performs than on how it was produced. This issue is also very important to project managers. Whether they are delivering a product that results from manufacturing or purely intellectual activity, the processes that produce that product have great effect on the outcome. What you do may keep a smile on your customer's face, but how you do it will keep you on schedule and on budget — and that may make the customer's smile even brighter and longer lasting.
* Customers — People who sell what they make may be very product focused in their view of quality. They seek to make products that are superior to those of competitors and always strive to be the best: "This is the best DVD player on the market today." This view of quality may have short-term utility, but can be limiting, even lethal, for the organization in the long term. Consider the boasts "This is the best carburetor on the market today" or "This is the best buggy whip on the market today." Both statements may be true, but if nobody is buying carburetors or buggy whips, are they relevant? People who make what other people want to buy have a different view of quality and it is rooted in what customers want. To these people, quality is defined by customers, their needs, and their expectations.
* Systems — A system is a group of things that work together. At a higher level of analysis, quality may be viewed as arising from things that work together. Products, defects, processes, and customers are all part of a system that generates quality, as are suppliers, policies, organizations, and perhaps some other things unique to a specific situation.
Traditional Definitions
Several definitions of quality already exist. In the now obsolete 3rd edition of his ground-breaking 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 organization that produced the products to understand the needs of its customers and to design products that are fit for use. In Juran's Quality Handbook, 6th edition, a revised definition appears. Quality is now "fitness for purpose." This new view is intended to be broader in scope and more universal in applicability, especially for service organizations that have risen to a larger role in the world economy since the appearance of the original definition.
Juran recognized the shortcomings of such a brief definition. He emphasized 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 organization. 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 Project Management Institute defines quality as "the degree to which a set of inherent characteristics fulfill requirements." This definition is taken directly from ISO 9000:2005, published by the International Organization for Standardization. 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.
One important aspect of quality does not come out in any of these definitions. 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 organization to a state of disorganization. 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, 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.
Quality and the Triple Constraint
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 tradeoffs among the triple constraint to meet project objectives. A project manager should never, never, ever trade off quality during project implementation.
Cost of Quality
Much misunderstanding exists about quality in spite of the various definitions in circulation. Quality is many things to many people, but quality is also not some things that have been assumed over time.
* An expensive process — One of the first questions asked when a quality improvement effort is proposed is "How much will this cost?" This is always a valid question, but an uninformed view can produce an invalid answer. Conventional wisdom, perhaps better called "conventional ignorance" in this case, has it that better quality costs more. In times of cost control and cost cutting, the answer to quality improvement can be an unwise "We can't afford that." Philip B. Crosby, another quality pioneer, addressed this in a book entitled Quality Is Free. Briefly, his point was that quality does not cost, it pays. When you improve the quality of a process, you reduce the defects that result from that process. While the new process may be more expensive — it may be less expensive, too — the resulting reduction of defects is something that pays back over and over and over. So if the payback is more than the cost, as it often is, quality is essentially free.
* An expensive product — This may be the greatest misunderstanding of all because of the tendency to view quality in terms of products. An automobile with leather seats and little mechanical wipers on the headlights costs more than one without these features. A fine "writing instrument" costs more than a plastic ballpoint pen. But price does not confer quality. Review the definitions of quality. None of them mentions price. Quality arises from an ability to satisfy customer needs. If a customer's goal is to spend a lot of money, then an expensive product may be viewed as top quality. Customers generally seek the lowest price for a product that meets their functional needs, not the highest. Considering accuracy and maintenance, an inexpensive digital watch from a drugstore provides better quality than a more expensive mechanical watch from a jewelry store. A customer may want the jewelry item, but only because it serves a purpose other than timekeeping, not because it is a better quality watch.
* Time consuming — "We don't have time" is the response that condemns an organization to poor quality. Urgency prevails and shipping dates or field requirements rule. The reality is that we always have time; we just choose not to use it wisely. The old adage "There's never enough time to do it right, but always enough time to do it over" is not just a clever collection of words; it is the truth. Poor quality in production leads to rework. Delivery of poor quality products leads to replacement, warranty charges, lost customers, and loss of reputation. In the long run, quality saves time and much, much more.
Crosby's statement that quality is free is good 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.
Failure
Failure costs may result from either internal or external failure. The major costs associated with internal failures, those that occur before a product has been delivered to a customer, are scrap and rework. At the end of some process, a product may not conform to prescribed specifications. The degree of nonconformance may be so severe that the product cannot be fixed and must be discarded. Any costs associated with production to this point are lost. This is scrap. In some cases, the degree of nonconformance may not be so severe. A reasonable amount of additional effort may bring the product into conformance, so the product is re-entered into the process and any additional work adds to the overall cost of production. This is rework. The costs of scrap and rework are more than the sum of lost product and additional work. Costs associated with disposal, storage, transportation, and inventory control must be included to determine total costs.
External failures, those that occur after a product has been delivered to a customer, may generate costs for repairs in accordance with product warranty obligations. They may also generate product recalls, which can be far more expensive. Consider the potential cost of fixing a defective part during assembly versus recalling 1.2 million automobiles to replace the defective part. Recall costs are orders of magnitude higher than repeat costs.
An external failure may also generate liability costs that are far more expensive. A coffeemaker that is improperly marked or includes defective temperature controls may produce coffee that scalds unsuspecting customers. Or worse, an automobile may be so poorly designed that when struck from the rear in an accidental collision, the fuel tank ruptures and ignites the fuel, which causes immolation of any passengers in the car. The cost in human suffering and loss of life cannot be calculated, but courts will do the best they can. Resulting awards in compensatory and punitive damages can be astronomic.
External failure costs include those associated with complaints and complaint handling. Organizations must pay specially skilled staff members to receive and respond to complaints. These employees must be empowered to offer satisfaction of various kinds, all of which have a cost. Loss of customers is a cost of nonconformance that has been characterized as unknown and unknowable. Suppose a woman buys an expensive silk blouse at a high-end boutique. She wears it to a special event where a careless guest spills something on it. She has it dry-cleaned, but notices on its return that one of the side seams has opened up. She takes it back to the boutique where her money is promptly returned because the shop stands by its products. Is the woman a satisfied customer? Sure, she got her money back, but what about all the inconvenience and disappointment? Will she ever shop there again? There is no way to tell because no device has yet been invented that will count the number of customers who do not come back through the front door. And what about her friends who will never shop there after hearing about her bad experience? Again, no device exists that will count the number of customers who do not come through the front door initially. There is a bit of wisdom in retail sales regarding the buying habits of dissatisfied customers: "The goods come back, but the customers don't."
(Continues…)
Excerpted from "Project Quality Management"
by .
Copyright © 2014 Kenneth H. Rose.
Excerpted by permission of J. Ross Publishing, Inc..
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Preface xi
About the Author xiii
Web Added Value™ xv
Section I Quality Foundations
Chapter 1 Understanding Quality in the Project Management Domain 3
Definition of Quality 4
Traditional Definitions 5
Quality and the Triple Constraint 7
Cost of Quality 7
Failure 9
Prevention 10
Appraisal 12
Benefits of Quality 13
Summary 13
Points to Ponder 14
Exercise 14
References 15
Chapter 2 Evolution of Quality and Its Contemporary Application to Projects 17
Progressive History 17
The Dark Ages 17
Scientific Management 18
Understanding Variation 19
Inspection Reigns 20
Japanese Quality 21
Customers and Systems 22
Quality Then and Now 22
The Wheel of Quality 23
Customer Focus 23
Variation 26
Continuous Improvement 27
Training and Leadership 28
The Wheel of Quality Model 29
Quality and Responsibility 29
Summary 30
Points to Ponder 30
Exercise 31
Reference 31
Chapter 3 Pioneers and Paradigms 33
Pioneers 33
Walter Shewhart 33
W. Edwards Deming 34
Joseph M. Juran 36
Philip B. Crosby 37
Kaoru Ishikawa 37
Genichi Taguchi 38
Paradigms 38
Six Sigma 38
ISO 9000 40
Baldrige National Quality Program 42
Closing Thoughts 43
Summary 43
Points to Ponder 44
Exercise 45
References 45
Section II Quality Management
Chapter 4 Project Quality Planning 49
Quality Management 49
Quality Planning 50
Quality Management Plan 50
Identifying Customers 51
Prioritizing Customers 54
Identifying Requirements 56
Prioritizing Requirements 58
Quality Planning and Project Planning 63
Identifying Standards 63
Example Case: Quality Planning 67
Situation 67
Analysis 68
Lessons Learned 69
Summary 69
Points to Ponder 70
Exercise 71
References 71
Chapter 5 Project Quality Assurance 73
Quality Assurance 75
Developing Assurance Activities 75
Metrics 75
Quality Assurance Plan 76
Quality Audits 77
Example Case: Quality Assurance 79
Situation 79
Analysis 80
Lessons Learned 81
Summary 81
Points to Ponder 81
Exercise 82
References 82
Chapter 6 Project Quality Control and Quality Improvement 83
Quality Control 83
Role of Inspection 84
Quality Control Tools 84
Quality Improvement 85
Reasons for Quality Improvement 85
Hurdles 86
Improvement Methodology 87
Example Case: Quality Control 89
Situation 89
Analysis 90
Lessons Learned 91
Summary 91
Points to Ponder 92
Exercise 92
References 93
Section III Tools for Managing Project Quality
Chapter 7 Collecting and Understanding Project Data 97
Tools for Collecting Data 98
Check Sheet 98
Tools for Understanding Data 102
Graphs 102
Histograms 103
Pareto Charts 107
Scatter Diagrams 111
Summary 115
Points to Ponder 115
Exercises 116
Chapter 8 Understanding Project Processes 117
Tools for Understanding Procesvses 117
Flowcharts 117
Run Charts 121
Control Charts 125
Summary 136
Points to Ponder 137
Exercises 137
Chapter 9 Analyzing Project Processes 139
Tools for Analyzing Processes 139
Cause and Effect Diagrams 139
Pillar Diagrams 144
Summary 147
Points to Ponder 148
Exercises 148
Chapter 10 Solving Project Problems 149
Tools for Solving Problems 149
Force Field Analysis 150
Brainstorming 153
Affinity Diagrams 157
Nominal Group Technique and Multi-voting 162
Summary 169
Points to Ponder 170
Exercises 170
Chapter 11 Common Project Practices 173
Commonly Used Tools 173
Compliance Matrix 173
Peer Review 176
Summary 177
Points to Ponder 177
Exercises 177
Section IV Quality in Practice
Chapter 12 Project Systems and Solutions 181
The Red Bead Experiment 181
Practical Exercise 184
Background 185
Data Collection 185
Requirement 186
Tips 186
Summary 188
Points to Ponder 188
Chapter 13 Why Not Quality? 189
Quality Disablers 189
The Bottom Line 189
Reluctance to Change 190
Offense at Improvement Suggestions 191
Problem-Solving versus Opportunity-Seeking 192
Culture 192
The Solution 193
Summary 193
Points to Ponder 194
Exercise 194
Epilogue 195
Appendix 1 Case Study: Dakota Wireless Network 197
Background 197
The Project 198
Appendix 2 Project Training 199
Internal Assignment 199
New Hires 200
Contract Labor 201
Training 201
Appendix 3 Project Leadership 205
Temporary Organizations 205
Ad Hoc Organizations 206
Eclectic Mixtures of Staff 207
Unique Ends 208
Appendix 4 Leading Change: A Model John Kotter 211
Index 217