Tài liệu We Cannot Trade Quality for Schedule or Budget! ppt

We Cannot
Trade Quality for
Schedule or Budget!
1-800-COURSES
www.globalknowledge.com
Expert Reference Series of White Papers
Abstract
It is not uncommon for people to say, “Fast, cheap, or good—choose two.” Most people interpret this to mean
that if you want a short schedule and a low budget, you must sacrifice quality. And the corollary is that if you
want quality, you must expect a longer schedule or higher costs.
But “quality” is not one of the “Triple Constraints”! The PMBOK
®
teaches us that every project must balance
time, cost, and scope. When budget and schedule are constrained, it is scope that must be given up, not quali-
ty! And it is increasing scope (not quality) that increases costs or schedules.
Quality vs. Grade
Where did people get the idea that quality costs more? It comes from confusion between the concepts of qual-
ity and grade.
“Grade” refers to the set of attributes on which the quality of a
product will be judged. For example, you can buy beef in various
grades (lik
e “prime” and “select”). The government has defined a
set of attributes for each grade concerning things like fat and gristle
content.
A low-grade cut of beef that meets all of the requirements
for its rating is indeed high-quality. While a high-grade cut that has
been in the display case too long is lacking in quality (even though it still meets the definition for its grade).
The grade of the product to be produced is one of the components of project scope, and so it can be traded for
cost or time
.
If you w

ant a softw
are product with lots of bells and whistles
,
then it will cost you more time or
money, while only one bell and two whistles will be significantly cheaper. The adage, “Fast, cheap, or good—
choose two,” is valid as long as we interpret the word good to be referring to grade, and not quality
Once the requirements for the product have been agreed upon, its quality refers to the degree to which it
meets those requirements. Producing a poor-quality product does not save time or money. In fact, as we will
discuss later
,
quality problems actually
cost
us time and money
.
Cost of Quality
The confusion between grade and quality is reinforced (especially in software development), because most of
us don’t adequately measure the cost of quality. Cost of quality has three components: defect detection; defect
correction; and defect prevention. Many organizations measure only the defect detection activities, and allow
the other two to be hidden within other costs.
Alan S. Koch, Global Knowledge Instructor, PMP
We Cannot Trade Quality for
Schedule or Budget!
Copyright ©2006 Global Knowledge T
raining LLC . All rights reserved. “PMBOK” and “Project
Management Body of Knowledge” are registered trademarks of the Project Management Institute.
Page 2
“Grade” refers to the set of
attributes on which the quality
of a product will be judged.
Defect Detection

Defect Detection is the set of activities that we normally associate with
software quality: preparing for testing; running tests; doing peer reviews
or software inspections; and maintaining testing tools, infrastructure,
and the testing group. These costs are almost always counted as quality
costs and show up in the budget (both project and department) as our
cost of quality.
Increasing the focus on product quality means allocating more resources to these activities. Since these tend to
be seen as non-value-added overhead activities, increasing their costs is difficult to justify. That is why it is
important to consider the other two components of cost of quality to determine what activities are justified.
Defect Correction
Defect Correction is the set of activities that are triggered by the discovery of defects. Of course it includes
reporting defects and managing the defect reports
. But that is a relatively small part of the cost. The major
defect correction cost is incurred by the engineers who must investigate and diagnose the problems, devise an
appropriate fix, and rework the product to bring it into compliance. In addition, this includes the cost to test
the fix and regression test the system to ensure that the fix did not introduce other problems. And if the prob-
lem was reported from the field, it includes the cost of distributing the fix and supporting the customers who
encounter the problem.
On most software projects, the engineering cost just described is merely counted as engineering cost, making
it an invisible cost of quality. Every time the engineers must fix a problem, the cost of the project increases. But
that increase is not accounted for as a cost of quality. In addition, the re-testing is counted as a defect detec-
tion cost, hiding it in the wrong part of our cost of quality.
Defect Correction is often the cause of budget and schedule problems on projects
, as the engineers and the
testers both spend unanticipated time and money dealing with defect correction.
Defect Prevention
Defect Prevention includes any activity that can prevent defects from being put in the product in the first
place. This includes requirements engineering, architecture and design activities, coding standards, process
improvement, and project retrospectives. Most organizations count these as overhead activities that are not
related to project performance, and so they minimize them or avoid them altogether.

If these were counted as costs of quality, then they could easily be managed to ensure that they are justified,
as we will discuss next.
Minimizing Total Cost of Quality
The way to control the budget and schedule on a project is to minimize the
total
cost of quality. Because many
of us only measure the defect detection costs, we think that minimizing those will save time and money.
Unfortunately, that can have the exact opposite result!
When we minimize defect detection costs (e
.g.
eliminating peer reviews and abbreviating testing), we usually
increase
defect correction costs. This happens because the defects are not found until, but they are found later
Copyright ©2006 Global Knowledge T
raining LLC . All rights reserved.
Page 3
Cost of Quality
• Defect Detection
• Defect Correction
• Defect Prevention
i
n the project, when they are more expensive to correct. By investing in defect prevention and early defect
detection, we can drive defect correction costs down. This results in minimizing our total cost of quality. At the
same time, it can compress our schedule as we save more time in defect correction than we spend in detection
and prevention.
Conclusion
So, you want to save time and schedule on your project? You can’t get there by minimizing quality. In fact, if
you invest in the right activities, you may be able achieve those goals and improve quality too!
Learn More
Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge.

Check out the following Global Knowledge courses:
Project Management Essentials
IT Project Management
Triple Constraints of Project Management
For more information or to register, visit www.globalknowledge.com or call 1-866-925-7765 to speak with a
sales representative. Our courses offer practical skills, exercises, and tips that you can immediately put to use.
Our expert instructors draw upon their experiences to help you understand key concepts and how to apply
them to your specific work situation. Choose from our more than 700 courses, delivered through Classrooms,
e-Learning, and On-site sessions, to meet your IT and Management training needs.
About the Author
Alan S. Koch, PMP, is a speaker and writer on effective Project Management
methods. He is a certified Project Management Professional and President
of
ASK Process
, Inc., a training and consulting company that helps
companies to improve the return on their software investment by focusing
on the quality of both their softw
are products and the processes they use to
development them.
Mr. Koch’s 29 years in software development include:
• 14 years designing,
developing and maintaining softw
are
• 5+ years in Quality Assurance (including establishing & managing
a QA department)
• 8 years in Software Process Improvement
• 10 years in Management
Mr
. Koch was with the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU) for 13 years where
he became familiar with the Capability Maturity Model (CMM), earned the authorization to teach the Personal

Software Process (PSP) and worked with Watts Humphrey in pilot testing the Team Software Process (TSP).
Mr. Koch:
•
Authored
Agile Software Development: Evaluating the Methods for your Organization
,
Artech House
• Authored "TSP can be the Building Blocks for CMMI",
Crosstalk Magazine
, March 2005
Copyright ©2006 Global Knowledge T
raining LLC . All rights reserved.
Page 4
•
Consulted with a variety of software organizations in their process improvement programs
• Has taught hundreds of professionals in numerous organizations and government agencies topics con-
cerning project management, process improvement, and software quality
• Receives high praise for his training classes
• Contributed to the accomplishment of several successful CMM-Based SPI efforts
• Was a team member on several CMM assessments and CMMI appraisals
• Presented at numerous recent software quality and process conferences
• Taught as an adjunct professor of Computer Science
• Mentored students in CMU’s Master of Software Engineering (MSE) Program
• Is an SEI-authorized PSP Instructor and TSP Coach candidate
• Is an SEI Transition Partner for the PSP and TSP
• Is a member of the Project Management Institute (PMI)
• Is a certified Project Management Professional (PMP)
• Is a member of the board of National Speakers Association, Pittsburgh Chapter
F
or more information about Mr. Koch’s education and experience, please refer to his resume at

/>Copyright ©2006 Global Knowledge T
raining LLC . All rights reserved.
Page 5