i need heeellllllppppp

sapna.hemnani

New member
pls help me out guys i've to do powerpoint presentation on COST OF QUALITY
m in SYBMS last date is 20th feb,07 i couldnt find any thing pls help me out
pls pls pls pls
 

gargi.n

Par 100 posts (V.I.P)
a superb info Quality cost analysis

What is Quality Cost Analysis?

Quality costs are the costs associated with preventing, finding, and correcting defective work. These costs are huge, running at 20% - 40% of sales. [3] Many of these costs can be significantly reduced or completely avoided. One of the key functions of a Quality Engineer is the reduction of the total cost of quality associated with a product.

Here are six useful definitions, as applied to software products. Figure 1 gives examples of the types of cost. Most of Figure 1’s examples are (hopefully) self-explanatory, but I’ll provide some additional notes on a few of the costs:[4]

Prevention Costs: Costs of activities that are specifically designed to prevent poor quality. Examples of "poor quality" include coding errors, design errors, mistakes in the user manuals, as well as badly documented or unmaintainably complex code.

Note that most of the prevention costs don’t fit within the Testing Group’s budget. This money is spent by the programming, design, and marketing staffs.

Appraisal Costs: Costs of activities designed to find quality problems, such as code inspections and any type of testing.

Design reviews are part prevention and part appraisal. To the degree that you’re looking for errors in the proposed design itself when you do the review, you’re doing an appraisal. To the degree that you are looking for ways to strengthen the design, you are doing prevention.

Failure Costs: Costs that result from poor quality, such as the cost of fixing bugs and the cost of dealing with customer complaints.

Internal Failure Costs: Failure costs that arise before your company supplies its product to the customer. Along with costs of finding and fixing bugs are many internal failure costs borne by groups outside of Product Development. If a bug blocks someone in your company from doing her job, the costs of the wasted time, the missed milestones, and the overtime to get back onto schedule are all internal failure costs.

For example, if your company sells thousands of copies of the same program, you will probably print several thousand copies of a multi-color box that contains and describes the program. You (your company) will often be able to get a much better deal by booking press time with the printer in advance. However, if you don’t get the artwork to the printer on time, you might have to pay for some or all of that wasted press time anyway, and then you may have to pay additional printing fees and rush charges to get the printing done on the new schedule. This can be an added expense of many thousands of dollars.

Some programming groups treat user interface errors as low priority, leaving them until the end to fix. This can be a mistake. Marketing staff need pictures of the product’s screen long before the program is finished, in order to get the artwork for the box into the printer on time. User interface bugs — the ones that will be fixed later — can make it hard for these staff members to take (or mock up) accurate screen shots. Delays caused by these minor design flaws, or by bugs that block a packaging staff member from creating or printing special reports, can cause the company to miss its printer deadline.

Including costs like lost opportunity and cost of delays in numerical estimates of the total cost of quality can be controversial. Campanella (1990) [5] doesn’t include these in a detailed listing of examples. Gryna (1988)[6] recommends against including costs like these in the published totals because fallout from the controversy over them can kill the entire quality cost accounting effort. I include them here because I sometimes find them very useful, even if it might not make sense to include them in a balance sheet.

External Failure Costs: Failure costs that arise after your company supplies the product to the customer, such as customer service costs, or the cost of patching a released product and distributing the patch.

External failure costs are huge. It is much cheaper to fix problems before shipping the defective product to customers.

Some of these costs must be treated with care. For example, the cost of public relations efforts to soften the publicity effects of bugs is probably not a huge percentage of your company’s PR budget. You can’t charge the entire PR budget as a quality-related cost. But any money that the PR group has to spend to specifically cope with potentially bad publicity due to bugs is a failure cost.

I’ve omitted from Figure 1 several additional costs that I don’t know how to estimate, and that I suspect are too often too controversial to use. Of these, my two strongest themes are cost of high turnover (people quit over quality-related frustration — this definitely includes sales staff, not just development and support) and cost of lost pride (many people will work less hard, with less care, if they believe that the final product will be low quality no matter what they do.)

Total Cost of Quality: The sum of costs: Prevention + Appraisal + Internal Failure + External Failure.



Figure 1. Examples of Quality Costs Associated with Software Products.


Prevention


Appraisal

Staff training
Requirements analysis
Early prototyping
Fault-tolerant design
Defensive programming
Usability analysis
Clear specification
Accurate internal documentation
Evaluation of the reliability of development tools (before buying them) or of other potential components of the product


Design review
Code inspection
Glass box testing
Black box testing
Training testers
Beta testing
Test automation
Usability testing
Pre-release out-of-box testing by customer service staff

Internal Failure


External Failure

Bug fixes
Regression testing
Wasted in-house user time
Wasted tester time
Wasted writer time
Wasted marketer time
Wasted advertisements [7]
Direct cost of late shipment [8]
Opportunity cost of late shipment


Technical support calls[9]
Preparation of support answer books
Investigation of customer complaints
Refunds and recalls
Coding / testing of interim bug fix releases
Shipping of updated product
Added expense of supporting multiple versions of the product in the field
PR work to soften drafts of harsh reviews
Lost sales
Lost customer goodwill
Discounts to resellers to encourage them to keep selling the product
Warranty costs
Liability costs
Government investigations[10]
Penalties[11]
All other costs imposed by law


What Makes this Approach Powerful?

Over the long term, a project (or corporate) cost accounting system that tracks quality-related costs can be a fundamentally important management tool. This is the path that Juran and Feigenbaum will lead you down, and they and their followers have frequently and eloquently explained the path, the system, and the goal.

I generally work with young, consumer-oriented software companies who don’t see TQM programs as their top priority, and therefore my approach is more tactical. There is significant benefit in using the language and insights of quality cost analysis, on a project/product by project/product basis, even in a company that has no interest in Total Quality Management or other formal quality management models.[12]

Here’s an example. Suppose that some feature has been designed in a way that you believe will be awkward and annoying for the customer. You raise the issue and the project manager rejects your report as subjective. It’s "not a bug." Where do you go if you don’t want to drop this issue? One approach is to keep taking it to higher-level managers within product development (or within the company as a whole). But without additional arguments, you’ll often keep losing, without making any friends in the process.

Suppose that you change your emphasis instead. Rather than saying that, in your opinion, customers won’t be happy, collect some other data:[13]



Ask the writers: Is this design odd enough that it is causing extra effort to document? Would a simpler design reduce writing time and the number of pages in the manual?



Ask the training staff: Are they going to have to spend extra time in class, and to write more supplementary materials because of this design?



Ask Technical Support and Customer Service: Will this design increase support costs? Will it take longer to train support staff? Will there be more calls for explanations or help? More complaints? Have customers asked for refunds in previous versions of the product because of features designed like this one?



Check for related problems: Is this design having other effects on the reliability of the program? Has it caused other bugs? (Look in the database.) Made the code harder to change? (Ask the programmers.)



Ask the sales staff: If you think that this feature is very visible, and visibly wrong, ask whether it will interfere with sales demonstrations, or add to customer resistance.



What about magazine reviews? Is this problem likely to be visible enough to be complained about by reviewers? If you think so, check your impression with someone in Marketing or PR.

You won’t get cost estimates from everyone, but you might be able to get ballpark estimates from most, along with one or two carefully considered estimates. This is enough to give you a range to present at the next project meeting, or in a follow-up to your original bug report. Notice the difference in your posture:

You’re no longer presenting your opinion that the feature is a problem. You’re presenting information collected from several parts of the company that demonstrates that this feature’s design is a problem.

You’re no longer arguing that the feature should be changed just to improve the quality. No one else in the room can posture and say that you’re being "idealistic" whereas a more pragmatic, real-world businessperson wouldn’t worry about problems like this one. Instead, you’re the one making the hard-nosed business argument, "This design is going to cost us $X in failure costs. How much will it cost to fix it?"

Your estimates are based on information from other stakeholders in this project. If you’ve fairly represented their views, you’ll get support from them, at least to the extent of them saying that you are honestly representing the data you’ve collected.

Along with arguing about individual bugs, or groups of bugs, this approach opens up opportunities for you (and other non-testers who come to realize the power of your approach) to make business cases on several other types of issues. For example:

The question of who should do unit testing (the programmers, the testers, or no one) can be phrased and studied as a cost-of-quality issue. The programmers might be more efficient than testers who don’t know the code, but the testers might be less expensive per hour than the programmers, and easier to recruit and train, and safer (unlike newly added programmers, new testers can’t write new bugs into the code) to add late in the project.

The depth of the user manual’s index is a cost-of-quality issue. An excellent index might cost 35 indexer-minutes per page of the manual (so a 200 page book would take over three person-weeks to index). Trade this cost against the reduction in support calls because people can find answers to their questions in the manual.

The best investment to achieve better quality might be additional training and staffing of the programming group (prevent the bugs rather than find and fix them).

You (in combination with the Documentation, Marketing, or Customer Service group) might demonstrate that the user interface must be fixed and frozen sooner because of the impact of late changes on the costs of developing documentation, packaging, marketing collaterals, training materials, and support materials.

Implementation Risks

Gryna (1988) [14] and Juran & Gryna (1980) [15] point out several problems that have caused cost-of-quality approaches to fail. I’ll mention two of the main ones here.

First, it’s unwise to try to achieve too much, too fast. For example, don’t try to apply a quality cost system to every project until you’ve applied it successfully to one project. And don’t try to measure all of the costs, because you probably can’t. [16]

Second, beware of insisting on controversial costs. Gryna (1988) [17] points out several types of costs that other managers might challenge as not being quality-related. If you include these costs in your totals (such as total cost of quality), some readers will believe that you are padding these totals, to achieve a more dramatic effect. Gryna’s advice is to not include them. This is usually wise advice, but it can lead you to underestimate your customer’s probable dissatisfaction with your product. As we see in the next section, down that road lies LawyerLand.

The Dark Side of Quality Cost Analysis

Quality Cost Analysis looks at the company’s costs, not the customer’s costs. The manufacturer and seller are definitely not the only people who suffer quality-related costs. The customer suffers quality-related costs too. If a manufacturer sells a bad product, the customer faces significant expenses in dealing with that bad product.

The Ford Pinto litigation provided the most famous example of a quality cost analysis that evaluated company costs without considering customers’ costs from the customers’ viewpoint. Among the documents produced in these cases was the Grush-Saunby report, which looked at costs associated with fuel tank integrity. The key calculations appeared in Table 3 of the report: [18]

Benefits and Costs Relating to Fuel Leakage

Associated with the Static Rollover Test Portion of FMVSS 208

Benefits

Savings — 180 burn deaths, 180 serious burn injuries, 2100 burned vehicles

Unit Cost -- $200,000 per death, $67,000 per injury, $700 per vehicle

Total Benefit — 180 x ($200,000) + 180 x ($67,000) + 2100 x ($700) = $49.5 million.

Costs

Sales — 11 million cars, 1.5 million light trucks.

Unit Cost -- $11 per car, $11 per truck

Total Cost — 11,000,000 x ($11) + 1,500,000 x ($11) = $137 million.

In other words, it looked cheaper to pay an average of $200,000 per death in lawsuit costs than to pay $11 per car to prevent fuel tank explosions. Ultimately, the lawsuit losses were much higher. [19]

This kind of analysis didn’t go away with the Pinto. For example, in the more recent case of General Motors Corp. v. Johnston (1992), [20] a PROM controlled the fuel injector in a pickup truck. The truck stalled because of a defect in the PROM and in the ensuing accident, Johnston’s seven-year old grandchild was killed. The Alabama Supreme Court justified an award of $7.5 million in punitive damages against GM by noting that GM "saved approximately $42,000,000 by not having a recall or otherwise notifying its purchasers of the problem related to the PROM."

Most software failures don’t lead to deaths. Most software projects involve conscious tradeoffs among several factors, including cost, time to completion, richness of the feature set, and reliability. There is nothing wrong with doing this type of business tradeoff, consciously and explicitly, unless you fail to take into account the fact that some of the problems that you leave in the product might cost your customers much, much more than they cost your company. Figure 2 lists some of the external failure costs that are borne by customers, rather than by the company.



Figure 2. Comparison of External Failure Costs Borne by the Buyer and the Seller


Seller: external failure costs


Customer: failure costs

These are the types of costs absorbed by the seller that releases a defective product.

These are the types of costs absorbed by the customer who buys a defective product.

Technical support calls
Preparation of support answer books
Investigation of customer complaints
Refunds and recalls
Coding / testing of interim bug fix releases
Shipping of updated product
Added expense of supporting multiple versions of the product in the field
PR work to soften drafts of harsh reviews
Lost sales
Lost customer goodwill
Discounts to resellers to encourage them to keep selling the product
Warranty costs
Liability costs
Government investigations
Penalties
All other costs imposed by law


Wasted time
Lost data
Lost business
Embarrassment
Frustrated employees quit
Demos or presentations to potential customers fail because of the software
Failure when attempting other tasks that can only be done once
Cost of replacing product
Cost of reconfiguring the system
Cost of recovery software
Cost of tech support
Injury / death


The point of quality-related litigation is to transfer some of the costs borne by a cheated or injured customer back to the maker or seller of the defective product. The well-publicized cases are for disastrous personal injuries, but there are plenty of cases against computer companies and software companies for breach of contract, breach of warranty, fraud, etc.

The problem of cost-of-quality analysis is that it sets us up to underestimate our litigation and customer dissatisfaction risks. We think, when we have estimated the total cost of quality associated with a project, that we have done a fairly complete analysis. But if we don’t take customers’ external failure costs into account at some point, we can be surprised by huge increased costs (lawsuits) over decisions that we thought, in our incomplete analyses, were safe and reasonable.
 
pls help me out guys i've to do powerpoint presentation on COST OF QUALITY
m in SYBMS last date is 20th feb,07 i couldnt find any thing pls help me out
pls pls pls pls

Hey sapna, as you mentioned you need information on cost of quality so i am going to provide you a document where you would find all the detailed information on cost of quality. All you need to do is to download my presentation and check it.
 

Attachments

  • COST OF QUALITY.pdf
    132.8 KB · Views: 0
Top