Tài liệu We Cannot Trade Quality for Schedule or Budget! - Pdf 84

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

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.

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

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


Nhờ tải bản gốc

Tài liệu, ebook tham khảo khác

Music ♫

Copyright: Tài liệu đại học © DMCA.com Protection Status