by Denise E. Robitaille and Johanna Rothman

A corrective action request, those official documents indicating that change looms for the status quo, presumes that a problem has been found in a product, process or quality system. In each case, the CAR identifies something that hasn’t met a specification. In most systems, a CAR links directly to a report, customer complaint or statement of nonconformance. Therefore, the initial nonconformity description gives the person responsible for dealing with the CAR a starting point for plotting a course through the process.

But before that happens, it’s important to define nonconformities as they relate to corrective action. These aren’t intended to be synonymous with categories used by regulatory agencies or registrars for indicating criticality or importance. Although those categories have value, they’re primarily helpful to the auditee in determining priorities.

If a corrective action has been requested, the assumption is that it has importance. If it were trivial, the auditor or other CAR initiator wouldn’t have wasted time or energy pursuing it. What follows is a description of nonconformities as they relate to a quality system.

Product, process and systemic nonconformities

A product nonconformity is a defect, omission or other event that clearly indicates a product hasn’t been developed or built to specification as defined in documents such as requirements specifications, contracts or purchase orders. This includes software problem reports indicating the product is against the code, or documentation and vendor material that has no visible defect but isn’t up to specification or is missing documentation.

If outsourcers or vendors supply part of your product, be aware that they could be providing nonconforming material. If the product is software that will be integrated into your product, you won’t be able to segregate the received defective material as required by ISO 9001:2000. (If you use that standard or some other quality management system, make sure you document what you do with externally supplied software.)

If product you order from a vendor doesn’t arrive as specified, it’s nonconforming and should be segregated. For example, if you order one version of a product but receive a different version, the product is nonconforming. Decide what to do about the different version before you automatically accept it and use it in, or with, your product.

A process nonconformity arises when an activity hasn’t been carried out according to documented procedure. The product resulting from the incorrect activity might meet specification but could have the following problems:

Developed using an uncontrolled or unapproved procedure, such as an outdated or incorrect building procedure

Improperly inspected, tested or verified, such as a product with insufficient testing (e.g., unit, integration or system testing)

Inadequately identified, such as source code insufficiently organized into a configuration management system

Improperly stored or labeled, such as masters for duplication

Any number of activities surrounding a product or process might not be carried out in accordance with documented requirements. This is a concern because process nonconformities could:

Reduce the customer’s confidence in the product

Increase the likelihood of error

Increase the risk of processes becoming more uncontrolled

Decrease the opportunity for conformity and repeatability

Undermine the integrity of quality records that provide evidence of conformity

A systemic nonconformity is less easily defined. It is also the most serious of all nonconformities. It identifies a quality management system failure that undermines an organization’s ability to maintain a system whose goal is the continued capacity to serve the customer.

Systemic nonconformities relate to such elements as:

Product development process

Document control system

Adequate corrective action program

Manner in which internal audits are conducted

Management review of the system

Management commitment to provide adequate resources

Nonconformity statement elements

A nonconformity statement includes three components: the nonconformity, the standard and the evidence. The first element--the nonconformity--describes what’s wrong so the reader can see the difference in the current state and the desired state of the product or process. For example:

Inspection records reveal that material was accepted that exceeded the allowable tolerance range.

No records exist verifying that the operator was qualified for the task he was performing.

Testing records aren’t kept in a central file and aren’t always readily available.

Testers tested a build with two smoke test errors although the process states that the testers shouldn’t test the product if the build has any errors.

The standard component indicates why the product or process is nonconforming. It cites the specific document that says so. Something fails to conform when it doesn’t agree with a documented and published process or standard. For example:

The upper bound for smoke test failure is defined in procedure ABC.

Procedure 4.18.1 states that inspectors must have completed in-house inspection training before conducting inspections without supervision.

ISO 9001:2000, Paragraph 4.2.4, specifies that “records that provide evidence of conformity to requirements… shall be readily identifiable and retrievable.”

The evidence element offers proof to support the finding of nonconformity. For example:

The smoke test automated e-mail shows 10 problems.

The records of training matrix was last updated in November 2000.

Each release sent to a customer must have the final test logs checked into the configuration management system. The test logs for the last two releases can’t be found.

An optional but often valuable fourth element--the “so what” clause--is an objective statement of the reason the nonconformity is of concern. It indicates why it’s a big deal that the:

Process sheet is signed

Backup schedule is followed

Revisions of released product match the configuration management system

Shipped documents match the software

This understanding gives the process owner a reason to move forward with both root cause analysis and a thorough corrective action plan. People like to know that what they’re doing has worth and isn’t just a futile exercise to fulfill a seemingly pointless requirement.

This also gives management the cost justification for the corrective action program and for the expense incurred in implementing it. If managers can see the concern and the potential benefit, they’re more likely to allocate time and resources to address the issue. Any time you make it clear that a nonconformity could lead to wasted time, an unhappy customer or delays in releasing product, you get management’s attention.

Your typical nonconforming statement should refrain from using names and, where possible, avoid referring to individuals. This helps the corrective process remain focused on a long-term solution rather than on laying blame.

Consider the difference between the following two statements:

The release engineer didn’t complete the build correctly.

The build logs from the final system test don’t provide evidence that the smoke test was completed.

The first statement says the operator screwed up; the second indicates that a piece of evidence leads to the conclusion that an activity wasn’t performed according to procedure. With the first statement, there’s no opportunity for further investigation. With the second, you get to ask, “Why?” The first assumes that the problem is simply that the operator failed to do something properly. The second allows you to question if the operation was completed, if it was necessary, if the build script kicks off the automated smoke test, if the process was done by an outside source (which might need to be recorded differently) or if the process has been changed and the documented procedure hasn’t been updated.

Nonconforming statements that identify individuals by name intimidate the auditees, who often confuse audits and the resulting CARs with performance reviews. They want to fix the mess and bury it as quickly as possible. They don’t care how it happened, and they’re not planning on letting it happen again--they just don’t want the boss to notice it. This leads to the most ubiquitous root cause, “operator error,” and its corrective action: “provide training.”

The downside of this mindset is that if the problem relates to inadequate staffing, incorrect documents or faulty machinery, it will never come to the attention of those responsible for providing the resources for meaningful corrective action.

It also short-circuits the possibility that developers, testers, writers or anyone on the product-development staff have discovered a more efficient process that saves the organization money. The only nonconformity is that they failed to revise the related documents--or at least tell their manager. They end up getting a black mark during a quality management system audit instead of the gold star they deserve.

A statement of nonconformity should be bloodless and leave out passion, sympathy, blame and outrage. It’s simply what Joe Friday asked for every week on Dragnet: “Just the facts, ma’am.”

Writing a problem report

For your product, each corrective action generally starts with a problem report or series of reports. It’s worthwhile to learn how to write a problem report well. It’s different from a software problem report, which is specific to a product and version of that product. However, you may use some of the SPR language in the corrective action problem report.

A problem report should have a title and state the:

Problem’s risk in the field

Actions that will reproduce the problem

Problem’s consequences

When you write up a problem report, whether it’s a CAR or an SPR, make sure you refer specifically to the problem’s consequences in the title. For example, a problem report titled “Typo in Install Script” doesn’t look like a big deal, something that the project team most likely would elect to fix in the next release.

However, if the report were titled, “Install Typo Causes First Time Users to Corrupt Their Databases,” it’s likely the project team would fix the problem immediately. This is an example of remedial action on an SPR. The criteria for moving on to corrective action would relate to the problem’s cause. You wouldn’t perform corrective action for a mere typo--unless a process nonconformity caused it. The process nonconformity heightens the risk of repeatedly releasing product with a problem that’s much more severe than a typo.

When you write a corrective action problem report, you might title it something like this: “Installation Scripts Deviate From Requirement’s Intent; First Time Users

Corrupt Database.” In the body of the corrective action problem report, you can explain the requirements, how the product development process allowed developers to create the problem and the risk of allowing this problem to continue. The history and effects of the product-development process make this a corrective action problem report, not just an SPR for remedial action.

Many organizations use several levels of priority and severity to deal with the problem risk. Then at the end of the release, they can play the demotion game with the problem reports, i.e., “It’s not really a three; it’s really a four.”

Priority and severity together don’t directly describe risk. If you find your organization playing the SPR demotion game at the end of a release, you may find it difficult to use priority and severity to make the case for corrective action.

If that occurs, talk about release risk first and then discuss risk for corrective action:

Critical. You must fix this before you release. If you don’t, you have substantial business risk (e.g., loss of customers and money or creation of safety issues for users).

Important. You’d like to fix this before you release, but it’s not safety-critical. It might annoy some customers, but you don’t think they’ll throw out the product or move to your competitors. If you don’t fix it before you release, you must either do something to that module or fix it in the next release.

Minor. You’d like to fix this before you die.

You can choose other terms, such as the Bellcore/Telcordia GR929 Appendix A definitions: critical, major and minor. These terms are defined by the effect the product defect has on the user, so they help you define priority with respect to the business or customer relationship. They help you decide what to do and when to do it.

These levels might not make you feel as good as severity and priority do, but they reflect more accurately what you must do with the product. If you have a high number of critical, important or minor problems, you can choose whether to create a corrective action plan to reduce the number of problems. When you assess according to priority or severity, you lose the ability to see the system--what kinds of problems you have and how many of each. Here’s the relative reference from ISO 9001:2000, clause 8.5.2: “Corrective actions shall be appropriate to the effects of the nonconformities encountered.” Thus, expending extensive resources on a defect with a miniscule risk leads to a misallocation of resources--the antithesis of a well-managed quality system.

If your organization doesn’t have trouble with the SPR demotion game before a release, you can use the risk of maintaining a product or system with a problem as a basis for the corrective action report. Discuss the probability of this problem’s recurrence and the severity if the problem does occur. However you choose to describe the risk, make sure you detail it in the problem report.

For product defects that require a series of actions to reproduce, make sure you list all the steps and what you expect to see at each step in the series. Part of your problem report might be that the documentation isn’t correct. In that case, describing what’s wrong in the problem report could help others realize there’s a problem with how the documentation is generated. That issue might be a candidate for corrective action. Remember that this is an evaluation step to decide whether to go forward with corrective action, including root cause analysis.

Similarly, if you’re dealing with a process problem such as “build used wrong components,” explain, step by step, how the problem occurred. Then management can decide how to proceed.

When you write problem reports, make sure you address the problem’s consequences. For corrective action purposes, note whether you’ve seen this problem or problems like this before. Including consequences is one of the tools you use to establish criteria. By prioritizing the severity of the problem and assigning a level of risk, you clarify whether transitioning to the corrective action process is appropriate.

Note: This article is excerpted from Corrective Action for the Software Industry. © 2004 by Denise Robitaille and Johanna Rothman. All rights reserved. For more information about this book, visit www.patonpress.com.

About the authors

Denise E. Robitaille has helped companies in diverse fields to achieve ISO 9000 registration. She’s an RAB-certified lead assessor, ASQ Certified Quality Auditor and senior member of the American Society for Quality. Robitaille is also a member of the U.S. TAG to ISO/TC 176, the committee responsible for updating the ISO 9000 standard series. She’s the author of numerous articles as well as The Corrective Action Handbook, The Preventive Action Handbook and The Management Review Handbook, all published by Paton Press.

Johanna Rothman promotes manager, team and organizational effectiveness with her pragmatic approaches to project management, risk management and people management. Rothman is an author and lecturer on managing high-technology product. She’s also a columnist for Software Development, Computerworld.com and StickyMinds.com, and publishes Reflections, an acclaimed quarterly newsletter about managing product development.