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 http://www.ASKProcess.com/experience.html. Copyright ©2006 Global Knowledge T raining LLC . All rights reserved. Page 5 . other costs. Alan S. Koch, Global Knowledge Instructor, PMP We Cannot Trade Quality for Schedule or Budget! Copyright ©2006 Global Knowledge T raining LLC. We Cannot Trade Quality for Schedule or Budget! 1-800-COURSES www.globalknowledge.com Expert Reference