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

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.. Cost of Quality The confusion between grade and quality is r

We Cannot Trade Quality for

Schedule or Budget!

Expert Reference Series of White Papers

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 (like “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 want a software 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!

“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 Training LLC All rights reserved Page 3

Cost of Quality

• Defect Detection

• Defect Correction

• Defect Prevention

in 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 software products and the processes they use to

development them

Mr Koch’s 29 years in software development include:

• 14 years designing, developing and maintaining software

• 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

• 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

For more information about Mr Koch’s education and experience, please refer to his resume at

http://www.ASKProcess.com/experience.html

Copyright ©2006 Global Knowledge Training LLC All rights reserved Page 5