Chapter 7. Project Quality 7-2

Transcription

1 Chapter 7 Project Quality 7-2

2 Objectives Part 1: Quality Management Understand the definition of quality and the different costs of quality Know how to build a quality management plan Part 2: Communications Management Understand the importance of possessing excellent communication skills Know how to build a communication management plan 7-3 Chapter 7 Part 1: Project Quality

3 Software Engineer, Software Project Manager, and Software Quality Manager positions available (as of March 5, 2013) Software Engineering positions available

4 Software Project Manager positions available Software Quality Manager positions available

5 Software Engineer, Software Projects and Quality: Examples from Industry Failed IT/Software Projects: Poor Quality Examples

6 Software Projects: Examples of Poor Quality In the U.S. software bugs cost organizations nearly $50-80 billion per year, according to the Commerce Department s National Institute of Standards and Technology (NIST). According to NIST, one-third of these costs could be eliminated with improved testing methods especially early in the development cycle The Pentium FDIV bug was a bug in Intel s original Pentium floating point unit. Certain floating point division operations performed with these processors would produce incorrect results. Intel eventually had to recall all of the initial chips and replace them once the flaw was found and fixed. Total loss: $ 486 M Faulty baggage-handling software at the then new Denver International Airport delayed the opening of the airport from October 1993 until February 1995 at an estimated cost of $1,000,000 a day The Northeast U.S. blackout of 2003 was a massive power outage that occurred throughout parts of the Northeastern and Midwestern United States and Ontario Canada. It affected an estimated 10 million people in Canada and 40 million people in the U.S. Outage-related financial losses were estimated at $6 billion. The initial cause of the outage was not due to a computer flaw but had the software been operating correctly the outage would have been greatly reduced. The Sustainable Computing Consortium, a collaboration of major corporate IT users, university researchers and government agencies, estimated that flawed (or buggy) software cost organizations $175 billion worldwide in 2001 Therac-25 was a radiation therapy machine produced by Atomic Energy of Canada Limited and CGR MeV of France. It was involved with at least six known accidents between 1985 and 1987, in which patients were given massive overdoses of radiation. At least five patients died of the overdoses due to a software bug 7-11 Failed IT/Software Projects: Poor Quality Examples

7 5 Top Causes of Poor Software Quality Source: Outcomes 1) NO Quality Management at all or minimal attention to Quality one of main reasons of software project failure. 2) These days, every global company has Vice-President on Quality, Total Quality Management, invests millions of dollars into quality, etc. 7-14

8 Project Quality Management

9 What Is Project Quality Management? Quality and Triple Constraints (Scope, Time, Cost) International Organization for Standardization (ISO) definition: Quality is the totality of features and characteristics of a product or service that bears on its ability to satisfy stated or implied needs Can be inflated for more quality or deflated for less quality. The American Society for Quality and the PMBOK define quality as the degree to which a set of inherent characteristics fulfill requirements. Text: the degree to which the product satisfies both stated and implied requirements 7-17 ISO Quality Management Principles Customer Focus Because Organizations rely on their customers, they must understand customer needs, they must meet customer requirements, and they must exceed customer expectations. Ex: 4-year activities on CS/CIS newest curriculum. Why? Answer: Customers (i.e. students) satisfaction and increase of graduate s market value Provide Leadership Project leaders must establish a unity of purpose and set the direction the organization should take using a unified mission and vision. They must create an environment that encourages people to achieve the organization's objectives. Use a Process Approach Each and every activity within the organization must be managed as a process leading to a more predictable outcome lowering costs and cycle time. Involvement of People The organization must involve people from all levels to promote ownership and support. Ex: Caterpillar: people, customer, stakeholders 7-18

10 ISO Quality Management Principles Take a Systems Approach approach each activity with the knowledge of how each and every process affects and is affected by other processes in the organization. Encourage Continual Improvement Organizations must create a permanent process which encourages continual improvement not a one and done approach. Mutually beneficial supplier relationships Organizations are dependent on their suppliers to be successful so they should foster a relationship built on trust and information sharing to create value for both parties Factual Approach to Decision Making Decision making should be based on actual, reliable, and current data. 7-20

11 Quality Management: Basic Terms Cost of quality total costs incurred by an organization to prevent a faulty product or development of a system that does not meet system requirements. Costs include: assessments, rework, lost time, injury, and death Prevention costs up-front costs associated with satisfying customer requirements (design reviews, all forms of system testing, training, surveys, etc.) Appraisal costs costs associated with assuring that all requirements have been met (customer acceptance tests, demonstrations, lab tests, etc.) Cost of non-conformance total costs incurred by an organization because the product does not meet user requirements for example, rework or poor user productivity Internal failure costs costs associated with system defects before a system is fully deployed (scrap and rework) External failure costs costs associated with system defects after fully deployed (scrap, rework, returns, market share, lawsuits, etc.) Rework due to poor quality the same task must be repeated to correct an identified error. Ex: write code again due to an identified bug Fitness for use the product can be used as it was originally intended 7-21 Quality Management Terms Conformance to requirements/specifications the product conforms to the written specifications Reliability the probability of the product performing as specified without failure over a set period of time Maintainability the time and expense needed to restore the product to an acceptable level of performance after the product has failed or began a trend toward failure 7-22

12 Quality Research: An Overview of Classic Methodologies Walter A. Shewhart W. Edwards Deming Joseph Juran Philip Crosby Kaoru Ishikawa Genichi Taguchi 7-23 W. Edwards Deming Deming estimated that a) as much as 85 percent of all quality problems could be corrected by changes in the process, and b) only 15 percent could be controlled by the workers on the (assembling, production) line 7-24

13 Pareto Principle and Software/IT Projects Attributed to a 19th century economist by the name of Vilfredo Pareto, who realized that 80% of the wealth in a given population was concentrated in the hands of 20% of the population, the observation has found its way into many disciplines. The 80/20 rule can be applied to almost anything: - 80% of customer complaints arise from 20% of your products or services. - 80% of delays in schedule arise from 20% of the possible causes of the delays. - 20% of your products or services account for 80% of your profit. - 20% of your sales-force produces 80% of your company revenues. - 20% of a systems defects cause 80% of its problems. Using the Pareto principle in SE/SD: a) 80 percent of the defects can be traced to 20 percent of all possible causes); b) 20 percent of software modules will produce about 80 percent of bugs; c) 80 percent of users will use ONLY 20 percent of functions; etc. Joseph Juran Often credited with adding the human element to quality control as well as statistical methods In 1951 he published the Quality Control Handbook, which put forth the view that quality should be viewed more from the customer s perspective fitness for use as opposed to the manufacturer s adherence to specifications Dr. Juran has also been credited with the Pareto Principle or 80/20 rule. As a general rule, a small amount of issues cause the most problems on a project. For example, 80% of the rework time spent on the product was caused by 20% of the requirements. 7-26

14 Kaoru Ishikawa In this work he created quality circles and development of the Ishikawa Diagram or commonly referred to as a Fishbone diagram because of its resemblance to the skeleton of a fish The Fishbone diagram is a cause-and-effect tool to aid managers in discovering the true root cause for quality issues 7-27 Modern Quality Assurance Methodologies: An Overview Total Quality Management (TQM) Six Sigma CMMI (Capability Maturity Model Integrated) Balanced Scorecard ISO 9000 provides minimum requirements for an organization to meet their quality certification standards 7-28

15 Total Quality Management (TQM) Total Quality Management (TQM) Total Quality Management (TQM) describes the culture, attitude and organization of a company that strives to provide customers (internal and external) with products and services that satisfy their needs TQM is a combination of quality tools and management specific tools to achieve increased business while reducing costs and waste Source:

16 TQM Components Employee empowerment training, commitment, full participation with reward and recognition programs tied to quality performance Management Involvement leadership, commitment, involvement, lead by example, support workers Decisions based on facts Statistical Process Control, rational vs. emotional decision making, accurate and timely data collection Continuous Improvement eliminate waste and non-value added activities, quality improvement is never complete, data is continuously collected, continually refine standards Customer-driven customer comes first, continued assessment of satisfaction and needs, strive to meet and exceed customer requirements Culture establish an open, cooperative, trusting, communicative environment where information can be easily shared up the management chain and back down 7-31 Total Software Quality: Overall Picture Software quality can be defined as: An effective process applied in a manner that creates a useful product that provides measurable value for those who produce it and those who use it. Software Engineering Framework Activities Planning Analysis/ Design Coding/ Testing Customer requirements Deployment Final SW product CONTRIBUTIONS to TOTAL SOFTWARE QUALITY Total Software Quality

17 Total software quality Total Software Quality, SW Quality Factors (groups), and SW Quality Metrics: A Hierarchical Approach TSQ = F (SQF1, SQF2, SQFn) SW quality factor SQF1 (group 1) SW quality factor SQF2 (group 2) SW quality factor SQFn (group N) SQFn = P (sqm1, sqm2, sqmk) A key element of any engineering process is measurement. Software quality factors and quality metrics provide a quantitative way to access the quality of internal product attributes, thereby enabling the software engineer to access quality BEFORE the final product is built. SW quality metric sqm1 SW quality metric sqm2 SW quality metric sqm3 SW quality metric sqmk Various types of software metrics provide the insight necessary to create effective analysis, reliable design models, solid source code, and thorough tests. Software Quality Metrics (more than 400) Initiation/Communication (getting input initial) Planning (resources, time, cost, etc.) Metrics for Software Project Planning Analysis/Modeling/Prototyping Analysis of requirements Design Models (Diagrams) Development (construction) Code generation Testing Metrics for Analysis Model Metrics for Design Model Metrics for Source Code Metrics for Testing Deployment/Implementation Metrics for Software Maintenance

18 Software Quality Factors: an example - Software Reliability Software Quality Dilemma IF you produce software with terrible quality THEN you loose because no one will use it IF you spend a lot of time AND a lot of money to create software system THEN you loose because you will be late on market or even go out of business without bringing the software to market The trick is to balance 1) the development (construction and testing) time and costs, and 2) the software product quality

19 The Bottom Line: Software System s Costs (an example) The relative costs to find and repair a software defect (bug, flaw) increase dramatically as we go from prevention to detection to internal failure to external failure costs. External failure costs are complaint resolution product return and replacement help line support warranty work Internal failure costs include rework repair failure mode analysis Prevention costs include quality planning formal technical reviews (FTRs) test procedures and equipment training Wow!!! 100+ times difference per a SW defect!!! Spending Money to Increase Quality Reduces Overall Cost of Software Development Project Source: %20of%20Quality%20Whitepaper.pdf

20 Software Reliability Software Reliability is defined as the probability of failure free operation of a software program in a specified environment for a specified time period Can be measured directly and estimated using historical and developmental data (unlike many other software quality factors) Measures of Software Reliability (examples): - Time to Failure (TTF) - MTTF = mean time to failure (mean of given values) - MTTR = mean time to repair - Mean time between failure (MTBF) = MTTF + MTTR - OS Availability = [MTTF / (MTTF + MTTR)] x 100% Number of units under review: ONE or MANY TTF # # # # # # # # # # # # OS Failure Data from over 5 years (unit of measure = in hour) Software Reliability vs Hardware Reliability Source:

21 Software Reliability: An Example Important Issue: Number of units under review: ONE or MANY Source: Multiple details on software quality measures, metrics, etc. are available in CIS573 course Quality Management in Computing (first time offering: 2013 Summer I - ONLINE course) CIS Quality Management in Computing (3 hours) Quality management topics relevant to advanced computing and software/hardware systems, including functional and structural quality, quality factors, McCall's triangle of quality, ISO standards, software quality assurance and management, COCOMO models, DFSS, CMMI, quality measurements and metrics. Cross listed with CIS 473. For cross listed undergraduate/graduate courses, the graduate level course will have additional academic requirements beyond those of the undergraduate course. Prerequisite: CIS 430 and CS 390, or equivalents; or consent of instructor.

22 Software Quality Manager positions available Six Sigma Methodology

23 Six Sigma Methodology A defect is any instance where the product or service fails to meet customer requirements Six Sigma for SW D&D projects is calculated based on the number of defects per million opportunities The main purpose of the Six Sigma quality methodology is to reduce variation thus reducing the number of product or service defects. It uses data and statistical analysis to measure and improve a company's operational performance by identifying and eliminating defects To reach Six Sigma level of quality you would have no more than 3.4 defects per million opportunities on your IT projects, for example, no more than 3.4 bugs per million of LOC (lines of code) The Greek letter Sigma (σ) is used in the field of statistics to represent the standard deviation to measure variability from the mean or average A small standard deviation means that data cluster closely around the middle (mean) and there is little variability among the data A normal distribution is a bell-shaped curve that is symmetrical about the mean Six Sigma: Just % vs. 6 Sigma ( %) Source:

24 Design For Six-Sigma (DFSS) and Motorola "Right now the culture is to test in quality. But we're asking our engineers to design in quality" Motorola, which led the way in Six Sigma for manufacturing, is also an early adopter of Six Sigma for software. "Right now the culture is to test in quality. But we're asking our engineers to design in quality," said Tricia McNair, director of Motorola's Software Design for Six Sigma (SDFSS) program and chairman of the Software Development Consortium and Six Sigma Software Academy. Goals: To address major performance flaws in requirements and architecture To improve on-time delivery and reduce defects To improve robust design and performance benchmarking To employ metric-based decision making for product development To utilize templates and criteria to support rigorous gate reviews To enable leadership to realistically set high expectations and demand evidence To provide tools, tasks and deliverables that clarify and support meeting those high expectations The term six sigma is derived from six standard deviations 3.4 instances (defects) per million occurrences implying an extremely high quality standard. Design For Six-Sigma (DFSS) and Software Engineering The term six sigma is derived from six standard deviations 3.4 instances (defects) per million occurrences implying an extremely high quality standard. The Six Sigma methodology defines three core steps: Define customer requirements and deliverables and project goals via well-defined methods of customer communication Measure the existing process and its output to determine current quality performance (collect defect metrics) Analyze defect metrics and determine the vital few causes. If an existing SW process is in place, but improvement is required, then 2 additional steps should be performed: Improve the process by eliminating the root causes of defects. Control the process to ensure that future work does not reintroduce the causes of defects.

25 Six Sigma in Action: IBM Corp. Source: Six Sigma in Action: Microsoft Corp. 7-50

26 Six Sigma in Action: Caterpillar Corp. and Cleveland Brothers, Inc ISO Chapter 9000

27 McCall s Software Quality Metrics Maintainability Flexibility Testability Product Revision Portability (Mobility) Reusability Interoperability Product Transition Product Operation Correctness Usability Efficiency Reliability Integrity They have tight relationship with ISO 9126 SW Quality Factors McCall s Software Quality Factors Correctness extent to which a program satisfies its specification and fulfills the customer's mission objectives Reliability extent to which a program can be expected to perform its intended function with required precision Efficiency amount of computing resources and code required by a program to perform its function Integrity extent to which access to software or data by unauthorized persons can be controlled Usability effort required to learn, operate, prepare input for, and interpret output of a program Maintainability effort required to locate and fix an error in a program Flexibility effort required to modify an operational program Testability effort required to test a program to ensure that it performs its intended function Portability effort required to transfer the program from one hardware and/or software system environment to another Reusability extent to which a program [or parts of a program] can be reused in other applications Interoperability effort required to couple one system to another

28 ISO 9000 Based in Geneva Switzerland, consortium of approx. 100 world s industrial nations. The American National Standards Institute (ANSI) represents the U. S. Quality system standard applicable to any product, service, or process anywhere in the world ISO:9000 defines the key terms and acts as a road map for the other standards ISO:9001 defines the model for a quality system when a contractor demonstrates the capability to design, produce, and install products or services ISO:9002 quality system model for quality assurance in production and installation ISO:9003 quality system model for quality assurance in final inspection and testing ISO:9004 quality management guidelines 7-55 ISO 9126 Six Key Groups of Software Quality Factors (Groups of Metrics) 1. Functionality (incl. 5 attributes) 2. Reliability (incl. 3 attributes) 3. Usability (incl. 3 attributes) 4. Efficiency (incl. 2 attributes) 5. Maintainability (incl. 4 attributes) 6. Portability (incl. 4 attributes) In general, each attribute may be characterized by various technical software metrics (for example, testability). Metrics for Analysis Model. Metrics for Design Model. Metrics for Source Code. Metrics for Testing.

29 ISO 9126 Six Key Groups of Software Quality Factors (Groups of Metrics) CMMI (Capability Maturity Models Integrated)

30 CMMI Methodology (for Software Development) CMMI Level 3 (only!!!)

31 Quality Management (QM) Planning 7-61 Quality Management Planning Components The quality management planning components are: 1. metrics (thresholds such as the number of software bugs allowed), 2. missed requirements, 3. system response time, 4. failure rates, 5. checklists (verify that a required set of steps was completed), 6. improvement plan (identify non-value added steps and remove/improve them), 7. a baseline of where the organization is currently operating Important to pick the correct metrics, what get measured is what gets attention Metrics: simple and easy to understand, inexpensive to use, robust, consistent, easily collected, and easily accessible by all stakeholders 7-62

32 Quality Management Plan 1) Standards and Metrics: -ilities Adaptability, Flexibility, Generality, Install-ability, Interoperability, Maintainability, Modifiability, Portability, Reliability, Replace-ability, Reusability, Scalability, Test-ability, Understand-ability, Usability 7-63 Quality Management Plan (cont.) 2) Return on Investment goals (Economy) 3) Efficiency 4) Documentation 5) Customer satisfaction criteria 6) Performance criteria 7) Number of change requests and time to implement 8) Earned Value 7-64

33 Quality Management Plan: an example Courses and textbooks on Software Quality Assurance (SQA), Software Quality Management (SQM) are available 7-65 QUALITY MANAGEMENT of your knowledge, education, degree, M.S. diploma, and concentrations Quality PLANNING: In order to get top quality educational outcomes: 1) SELECT by yourself courses that you really NEED for your professional career (or, create YOUR OWN TOP QUALITY program of study); 2) ask questions about those courses; 3) plan courses per each semester WISELY and IN ADVANCE. Quality-related questions: 1. What courses will meet my professional goals with a maximum rate? 2. What courses will provide me with: - maximum salary? - maximum market value? - maximize opportunities to get a position that I want? 3. What are course outcomes in terms of state-of-the-art knowledge area, newest technology and tools that are in demand by industry, state-of-the-art projects, etc. 7-66

34 Chapter 7 Project Quality Additional Information Balanced Scorecard An approach for managing and measuring business performance which takes into consideration factors beyond the typical financial metrics. It is in a form of a semi-standard structured report. The key new element of this approach is focusing on the human issues that drive financial outcomes to force organizations to focus on the future. The balanced scorecard suggests viewing organizational activity from four perspectives: Learning and growth training, continuous improvement, investment Business process reduce non-value added activities, number of opportunities and success rates Customer perspective customer satisfaction and needs, delivery performance Financial ROI, shareholder value, Return on equity, Cash flow The key issue with implementing a balanced scorecard is to make sure you pick the right software project, process and product metrics. 7-68

35 Balanced Scorecard Source: Quality Management (QM): other models 7-70

36 Capability Maturity Model Integrated (CMMI) Federally funded research and development center sponsored by the U.S. Department of Defense through the Office of the Under Secretary of Defense for Acquisition and Technology The SEI contract was competitively awarded to Carnegie Mellon University in December 1984 The U.S. Department of Defense established SEI to advance the practice of software engineering because quality software is a critical component of U.S. defense systems The quality of a system is highly influenced by the quality of the process used to acquire, develop, and maintain it This premise implies a focus on processes as well as on products This is a long-established premise in manufacturing (and is based on TQM principles as taught by Shewhart, Juran, Deming, and Humphrey) Belief in this premise is visible worldwide in quality movements in manufacturing and service industries (e.g., ISO standards) 7-71 Maturity Model: An Overview A maturity model is a structured collection of elements that describe characteristics of effective processes. A maturity model provides a place to start the benefit of a community s prior experiences a common language and a shared vision a framework for prioritizing actions a way to define what improvement means for your organization A CMMI model provides a structured view of process improvement across an organization. CMMI can help integrate traditionally separate organizations set process improvement goals and priorities provide guidance for quality processes provide a yardstick for appraising current practices 7-72

37 Maturity Model: An Overview Models in Four Disciplines Systems Engineering (SE) Software Engineering (SW) Integrated Product and Process Development (IPPD) Supplier Sourcing (SS) Substantial reduction in systems integration and test time with greater probability of success Cause integration of, and interaction among, the various engineering functions Extend SW-CMM benefits to the total project & organization Employ systems engineering principles in software development Increase & improve SE content in programs Leverage previous process improvement investments 7-73 Organizational Project Management Maturity Model (OPM3) Organizational Project Management Maturity Model (OPM3) Is universal, supporting all types of projects and organizations, across the world. The OPM3 maturity model has four levels of maturity, and each level can exist at different domains of project management. The three domains of project management are portfolio, program, and project As a general rule, organizations new to organizational project management maturity are encouraged to begin at the individual project stage and gain maturity before moving on to maturity in their project management practices for programs and then portfolios Standardize A standard process, with defined deliverables, is adopted. Measure Metrics are created and measured. Control Actions are taken, based on facts gathered to improve the project. Continuously improve Modifications are made to improve the process with each project 7-74

38 Steps to Conducting the Communication Planning Process 1. Review the stakeholder analysis and add information if necessary pertaining to communications management and complete the stakeholder communications matrix. 2. Define content for status reports and timing 1. Establish who on the project team is responsible for collecting data for status reports 2. Establish who on the project team is responsible for creating the reports and disseminating the reports 3. Establish key project team contacts for each stakeholder to serve as first contact references 4. Finally, accumulate information from previous steps and build the Communications Management Plan 7-75 Walter A. Shewhart In 1924, Shewhart created the control chart to better understand variation and to distinguish between assignable-cause and chancecause In order to aid a manager in making scientific, efficient, economical decisions, he developed Statistical Process Control methods He also believed that quality must be a continuous process and developed what is referred to as the PDSA cycle: Plan, Do, Study and Act which was later extended and made famous by W. Edwards Deming 7-76

39 W. Edwards Deming 14 Points 1. Create constancy of purpose toward improvement of products and services, the aim to become competitive, and to stay in business, and to provide jobs 2. Adopt the new philosophy of cooperation (win-win) from management on down to all employees, customers, and suppliers 3. Cease dependence on inspection to achieve quality 4. End the practice of awarding business on the basis of price tag alone. Instead minimize total cost over the long run 5. Improve constantly and forever every process for planning, production, and service. This will improve quality and productivity and thus, continually reduce costs 6. Institute training on the job 7. Adopt and institute leadership for the management of people, recognizing their different abilities, capabilities, and aspirations 8. Drive out fear and build trust so that everyone may work effectively 9. Break down barriers between staff areas (departments). Abolish competition and build a win-win system of cooperation 10. Eliminate slogans, exhortations, and targets for the work force asking for zero defects or new levels of productivity 7-77 W. Edwards Deming 14 Points 11. Eliminate numerical quotas for the work force and numerical goals for management and substitute leadership 12. Remove barriers that rob people of workmanship. Eliminate the annual rating or merit system and create pride in the job being done 13. Institute a vigorous program of education and self-improvement for everyone in the organization 14. Put everybody in the company to work to accomplish the transformation 7-78

40 Juran s 10 Steps 1. Build awareness of the need and opportunity for improvement 2. Set goals for improvement 3. Organize to reach the goals (establish a quality council, identify problems, select projects, appoint teams, designate facilitators). 4. Provide training 5. Carry out projects to solve problems 6. Report progress 7. Give recognition 8. Communicate results 9. Keep score 10. Maintain momentum by making annual improvement part of the regular systems and processes of the company 7-79 Philip Crosby Best known for the phrase zero defects or doing it right the first time He spent most of his career educating managers that preventing defects was cheaper than fixing them later Ex: Intel, PII processor, total loss: $486 M He believed that quality is free because the cost of conformance should be counted as the normal cost of doing business and that the cost for nonconformance is the only cost of quality Crosby s Principles: Conformance to requirements Prevention over inspection and rework The standard should be zero defects. Measured by the cost of nonconformance 7-80

41 Genichi Taguchi Quality should be designed into the product and not inspected into it Quality is best achieved by minimizing the deviation from a defined target reducing the affect of uncontrollable environmental factors Cost of quality should be measured as a function of deviation from the standard and collected system-wide (scrap, rework, inspection, returns, warranty service calls, product replacement) 7-81 ISO 9000 Issues Can be a paperwork nightmare when starting from scratch Does not guarantee that an organization will produce quality products or services. It only confirms that the appropriate system/process is in place. Time consuming and cost money, ROI doesn t happen right away 7-82

42 Six Sigma: Goals Source: Six Sigma Process: DMAIC Referred to as DMAIC (dee-may-ic): Define determine customer quality goals Measure setup relevant metrics based on customer goals and collect data Analyze evaluate data results for trends, patterns, relationships. Improve make changes based on facts Control don t slip backwards once targets are reached but set up control methods to maintain performance Source:

43 Six Sigma: Players Source: Microsoft and QM Software Systems

44 Six Sigma in Action Source: Steps to Conducting the Quality Planning Process 1. Obtain commitment and shared understanding from stakeholders on the quality standards to be used on this specific project. 2. Conduct training for all on the Organization s quality initiative (Six Sigma, TQM, CMMI) 3. Define the quality standards which consist of metrics (goals) to be measured and the acceptable result parameters 4. Determine how each metric result will be collected and who is responsible for collecting each data item. 7-88

45 Recommendation Engines