Q: I work in the Intel software quality group, and I have a few questions that pertain to defining the task categories for cost-of-quality reporting:
- How do we classify project management efforts such as facilitating project meetings and managing day-to-day project development? Are these creation or prevention costs?
- In software development, we have a requirement analysis that is done up front to explore the feasibility of implementing customer requirements, followed by requirement development. Is requirement analysis considered prevention or appraisal? And how does requirement analysis differ from requirement document review?
- We also have a software configuration management system. How should we categorize efforts to set up and maintain the system, as well as activities to build software for development, test and release?
Soo Min Ooi
Sungai Ara, Malaysia
A: First, I should point out that the definitions of the various cost-of-quality elements—such as facilitating meetings, requirement analysis and configuration management—may vary from one organization to another.
Due to this variation, each organization needs to discover for itself how it applies these elements in managing its process quality systems.
In Appendix A of my book, The Executive Guide to Understanding and Implementing Quality Cost Programs, I list the basic elements of quality cost.1 These are defined in terms that are not industry specific, so your team will need to redefine them to fit your organization’s terminology.
I use the PAF model, with costs being allocated to prevention, appraisal, internal failure or external failure. Of course, many measured costs are a cost of doing business and not part of quality costs.
During the ASQ cost-of-quality course, we do an exercise that helps a group gain clarity around these categories of cost. You should consider arranging for ASQ to hold this course at your organization, so your group working on this measure can gain a common understanding of how these costs can be categorized at Intel.
Now, let’s move on to your questions:
1. Day-to-day project development sounds like a business cost. Even if it is related to project development, it would be a cost of doing business if it is done on every project.
If project development is performed only when a deficiency has been found in a current or prior project, then it could be called prevention. Prevention costs are costs incurred to increase the reliability of a process control system, other than to measure the level of quality or to correct a problem on a current business process. Again, you can find examples in appendix A of my book.
Facilitating a project meeting would also be a business cost, unless the meeting involves a discussion of improving project robustness after an identified deficiency. Also, if the meeting trains attendees on basic tools for quality—such as sampling, Pareto charts and statistical process control—you can classify this as a prevention cost.
In general, project management efforts to improve the general quality of your software development processes would be prevention costs. But be careful to focus your definitions on the desired results of the meetings, not just the title of the meeting.
2. Is requirement analysis performed for every project? If so, it is most likely a cost of business and probably not appraisal. Appraisal costs occur when the status of a process is measured and data are collected to ascertain if the process is meeting requirements. The decisions about whether this process meets requirements may also be considered appraisal cost.
Requirement document review sounds more like an appraisal cost. Appraisal is an inspection of work already done. You can refer to my previous answer about efforts to improve the general quality of your software development processes when considering prevention.
You may not have prevention activities in place that align with all of your failure costs. This is commonly true, even in well-run organizations. No one has considered your costs in a PAF framework before, so there hasn’t been an opportunity to align prevention and failure costs.
Don’t force your costs to fit so you have something in each category. If the activities to prevent systemic project failure costs do not exist, then they need to be established. Most organizations increase their prevention costs significantly after mapping their quality costs. Appraisal cost may increase or be shifted to more critical areas.
3. Many of the software configuration management activities that tie into scheduling and cost measurement are part of the cost of doing business. But aspects that focus on preventing known defects or measuring how well the software meets requirements (appraisal) and fixes deficiencies (failure) may be quality cost elements.
If a software developer is in a situation where he or she needs to rework code, that activity is a candidate for failure cost. There may be some failure costs you find difficult to measure. These should be noted for future opportunities but not tracked. Adding too many small elements will dilute your effort.
Setting up and maintaining the software systems are likely prevention costs, provided they are activities that relate to avoiding noncompliance to requirements. Building software for development might be prevention, and building software for testing would be appraisal.
I realize these categories are not likely to fit the usual scheme of how you categorize costs. This is the value of the PAF model. It helps you see the connections upstream and downstream relating to failure costs—rework or nonvalue-added costs—so you can manage a more robust control system.
I strongly encourage you to hold an internal training session to help your whole team understand the elements and steps in building your quality cost system. If you think there is no time to do this now, remember the old saying: "There is never enough time to do it right, but always enough time to do it over."
To that, I say if there is time to do it over, why not take that time to make sure you do it right the first time?
D.C. Wood Consulting
Overland Park, KS
- Douglas C. Wood, The Executive Guide to
Understanding and Implementing Quality Cost Programs, ASQ Quality
Q: When you conduct a system audit of a supplier, is it more effective to audit the supplier’s compliance to the documentation and requirements established in its management system documentation—such as compliance to their manual and procedures—or should you audit its compliance to the requirements of the standard it’s certified to, such as ISO 9001:2008?
I understand that the quality system used by the supplier may be based on the framework of the higher standard, but I’ve always left it up to the supplier’s registrar to audit the supplier’s compliance to that standard.
Additionally, not all of our suppliers are ISO-certified, so I’ve always avoided auditing a supplier to a standard to which they are not registered. Therefore, I’ve always elected to audit a supplier’s compliance strictly to the content of their quality manual and procedures.
A: I agree it is more effective and valuable to audit the supplier’s conformity to the documentation and requirements established in its management system documentation than to audit its compliance to the requirements set forth in a higher standard it is certified to, such as ISO 9001.
You also should audit the supplier against any requirements your organization has specified in a contract or other documentation. Its management should be informed of noncompliance issues regarding regulatory or legal requirements you observe.
Reporting a nonconformity against a management system standard such as ISO 9001 could get rather thorny for you if the certification body has not reported it or has approved it as-is. If you observe something you think is inconsistent with the requirements of the management system standard, you can report it as an observation or potential nonconformity.
The higher-value auditing involves auditing organizations against existing processes—in other words, whether they do what they say.
J.P. Russell & Associates
Gulf Breeze, FL
For more information
Russell, J.P., "Better Together," Quality Progress, June 2010, pp. 68–70.