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.
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
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
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
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
The upper bound for smoke test failure is defined in procedure
Procedure 4.18.1 states that inspectors must have completed
in-house inspection training before conducting inspections
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
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
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
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
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.”
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
A problem report should have a title and state the:
Problem’s risk in the field
Actions that will reproduce the problem
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
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
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.
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
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.