Only the online system has the current version.

Verify hard copy against online system before use.

CAUSE ANALYSIS
AND
PREVENTIVE
CORRECTIVE ACTION GUIDE
FOR SUPPLIERS

SQ&TP 0110
Revision Date: 07/18/03

J. Saliture, Director, SQ&TP

Suppliers may view this document via the Internet at https://oasis.northgrum.com.

REVISION RECORD
The latest issue to this guide may be confirmed by viewing the OASIS web site (address is shown
on the cover).
REVISION

DATE

Original Issue

7/18/03

REVISION

DATE

ii

REVISION

DATE

TABLE OF CONTENTS
CHAPTER

PAGE

Expectations.................................................................................................................................iv
Overview......................................................................................................................................1
Introduction..................................................................................................................................2
Flow Chart ...................................................................................................................................5
Event ............................................................................................................................................6
Collection.....................................................................................................................................7
Analysis........................................................................................................................................13
Solution ........................................................................................................................................24
Assessment...................................................................................................................................37
Reference .....................................................................................................................................41

ATTACHMENTS
(A) Using 5 WHY Analysis.......................................................................................42
(B) Risk Decision Guide ...............................................................................................43
(C) SCAR Review and Approval Guide .......................................................................51
(D) Supplier Corrective action Request (SCAR) ..........................................................52

iii

EXPECTATIONS OF BUSINESS ASSOCIATES

Continuously evaluate the effectiveness of the corrective action process.

Provide a process that effectively handles customer complaints and reports of product or
quality system deficiencies in a timely manner commensurate to the needs of the
customer.

When product is affected, take immediate steps to capture, control,and document the
status of all work in process, and inventory, including product already delivered or in
transit.

Provide customers timely disclosure of nonconforming materiel in transit or delivered

post-discovery.

Initiate immediate interim corrective action needed to eliminate the direct cause of an
event, and document the actions taken to correct the discrepancy.

Conduct a thorough cause analysis of each event relating to product, process, and quality
system that looks beyond the obvious to the degree appropriate, commensurate to the
magnitude of the problem with the risk encountered.

Identify and document effective corrective action measures taken to prevent recurrence of
contributing and root causes.

Provide the customer a Correction Action Report that documents the investigation and
analysis, corrective actions, management approval, and assessment of the effectiveness of
the identified corrective action; both immediate and preventive.

Maintain objective evidence that supports the verification of corrective action

effectiveness.

Provide sufficient notification and justification to the customer when committed corrective
action dates of corrective action cannot be met.

iv

OVERVIEW
Cause analysis and preventive corrective action is a process of finding cause and facilitating
corrective actions to prevent the potential of recurrence of an event(s) that, if left unchecked, will
ultimately lead the customer and suppliers to unrealized costs associated with rework, repair, and
replacement at all levels of manufacture.
This process is an integral part of Total Quality and Six Sigma practices. An ISO/AS/EN 9001
quality management system standard requires manufactures to have corrective and preventive action
processes that are used throughout the manufacturing facility.
Effective preventative corrective action concepts build on the traditional corrective action process,
yielding a more robust process in every aspect of its application to product, process, and quality
system. The resulting cost savings benefit both the supplier and customer.
Northrop Grumman Integrated Systems recognizes that an effective Corrective and Preventive
Action process will assist in achieving cost reductions in manufacturing, improve the desired level of
quality excellence, and promote on time delivery.
This document is based on corrective and preventive action concepts discussed in a cause analysis
and mistake proofing document prepared by Allied Signal for the United States Department of
Energy. Northrop Grumman Integrated Systems encourages suppliers of manufactured goods and
services to aggressively pursue adapting cause analysis, corrective and preventive action, and mistake
proofing concepts into all levels and aspects of their business process, product, and quality system.
Suppliers are encouraged to utilize manuals and guidelines posted on the OASIS web site.
Assistance and training can be arranged upon request through your assigned process manager.

INTRODUCTION
Cause Analysis and Preventive Corrective Action (CA/PCA):
1. Is an effective process for finding the causes of an event, facilitating
effective corrective actions, and preventing the recurrence of events
2. Is an excellent tool for streamlining processes, solving problems, and
reducing
processing time
3. Will increase processing speed as confidence and experience is gained
Goal: Provide an understanding of the concepts of CA/PCA and its application to prevent and/or
eliminate errors and defects.
Objectives:

Define the CA/PCA steps for implementation and/or modification to improve

existing methods.

Understand the importance of team dynamics and data collection.

Illustrate the importance of constructing cause chains and their relevance to the
identification of cause types.

Look at the WHY questioning method and its importance to the analysis of problems.

Define corrective action solution types.

Discuss the importance of follow-up and effective measurement of corrective action.

Define report documentation, data collection, analysis, solution, and assessment.

Cause analysis and preventive corrective action can provide you the right path.

B u s in e s s P ro c e s s e s

In te rn a l A u d it
F in d in g

B u s in e ss
p la n n in g a n d
s u p p o rt

P ro to typ e a n d
Q u a lifica tio n
re su lts

D e s ig n

S u p p lie r
P ro c e s s e s

P ro d u c t d e fe c ts
and SPC

P ro d u c t
D e live ry

C o rre c tive
A c tio n P ro ce s s

C u sto m e r
R e tu rn s a n d
A u d its

C u s to m e r
S u p p o rt

Corrective action Process is the feedback system for your business:

All corrective actions should flow through a single corrective action process.

Have we learned anything? If the company keeps making the same mistakes, it may be caused
by a disconnected feedback system. We must learn from our mistakes; otherwise large amounts of
time and effort will be consumed in continuous, repetitive firefighting drills.

Traditional Problem Solving:

Don't m ess
w ith it

Does
anyone know
you m essed
w ith it ?

YES
NO

YES

Does it
w ork?

NO

You could be
in trouble !

YES
YES

NO

W ill
you be
blam ed for it
any w ay ?

Can
you transfer
blam e to som eone
else ?

NO

OH - OH!
Can
it be fixed before
your boss finds
out ?
Hide it or
throw
aw ay the
evidence !

Did
you m ess
w ith it?

NO
YES

TOO BAD

YES

NO

NO PROBLEM

Its time to break from tradition and put out the fires. Lets get started down the right path. The
following diagram illustrates the Cause Analysis and Preventive Corrective Action (CA/PCA)
process. The following discussion is broken into 5 parts. They are Event, Collection, Analysis,
Solution, and Assessment.

EVENT

Docum ent
T eam

Id e n tify T e a m

C O L L E C T IO N

Id e n tify P r o b le m

G a th e r D a ta

Docum ent
Causes

D e te r m in e C a u s e

A N A L Y S IS

D ir e c t

ROOT

C o n tr ib u tin g

Docum ent
C o r r e c t iv e
A c tio n

D e te r m in e C o r r e c tiv e A c tio n

S O L U T IO N

S p e c ific

P r e v e n tiv e

M is ta k e P r o o fin g

ASSESSM ENT

NO

Docum ent
F o llo w -U p

Im p le m e n t & F o llo w U p

S o lu tio n
A c c e p ta b le
?

YES

Is s u e
R e p o rt

EVENT
An event is an undetected error from which problems are derived and ultimately drives the need
to conduct a corrective action investigation. Cause Analysis and Preventive Corrective Action
(CA/PCA) is triggered by such an event.
EVENT
All-inclusive term for things like:

Product failure

Audit finding

Special cause

Accident

Customer complaint

The solution to the event is the CA/PCA process built around four key elements that are referred
to as Collection, Analysis, Solution, and Assessment.

Risk Analysis consideration. Once the CA/PCA process is established and stable, risk
assessment should then be considered. When conducted in a scientific manner, risk analysis will help
identify the essential few or the most critical problems that need to be pursued through the CA/PCA
process, hence, better management of vital resources. Typically, stakeholders would conduct a risk
decision analysis and have it approved by single point of contact (SPOC) before starting the
collection phase of the CA/PCA process. A Risk Decision Guide is attached at the end of this guide.

PROCEED WITH CAUTION!

It is important that there is a clear understanding of the how-to-do-it concept of CA/PCA as
presented in this guide. The concepts, once realized and implemented, must become stable before
moving into risk assessment

COLLECTION

In order to identify the appropriate cause(s) of a problem associated with an event, you must start
with the collection phase. This phase of the CA/PCA process engages fact-finding that is made up of
three elements: team identification, problem identification, and data gathering. Documentation of the
activity carried out in each of the elements is necessary to support completion of the final report.

Identify Team

Identify Problem

Gather and Verify Data

Document
Team

IDENTIFY THE TEAM

A team provides the critical control and feedback that the process must have to achieve optimum
results. The team dynamic assures that the outcome of the corrective action will be successful in
implementing preventive measures. Management empowers the team members with the responsibility
and authority over their process.
There are two groups that make up the teams membership during the data collection phase: the
natural work team and the qualified team.
The natural work team members, or stakeholders, must have a vested ownership in
resolving situations:

They know their process(es).

They have the data and experience.

They have to live with the corrective actions.

They will make it work if given the chance.

They depend on the process.

The qualified team members are consulted, as required by the natural team members, to provide
technical support. They include:

Those who can provide additional information

Those who have particular technical expertise

Those who may be needed to act as advisors

Those providing management support.

The natural team will identify and integrate other team members as the investigation unfolds.
Once a natural team begins the data gathering process, they will identify the need to bring in other
people as natural or qualified team members. Qualified team members are ad hoc members in that
they act as advisors to the natural team members on an as-needed basis. The natural team must know
when to bring in a qualified team and identify the resources available for use on the qualified team.
A core team of three to five people works the best; a team that becomes too large may become
uncontrollable. Bring qualified members in as you need them, drop them off when they are no longer
required, and maintain a running roster of the member participation.

No Team? No Process! Questionable Results!

Assigning CA investigations to someone with no vested interests or expertise to conduct an
investigation on their own, or forming a team that doesnt have ownership of the problem, will yield
unsatisfactory results. Its important to understand that the natural team provides the critical control
and feedback the process must have to succeed but only if they have the responsibility and authority
over their process.
A team should never be less than two people; even on simple problems, the synergy that comes
from two people sharing ideas adds greatly to the process.
Team members from different backgrounds and responsibilities bring different ideas and
experiences to the table; the team process capitalizes on these factors.
ESTABLISH A SINGLE POINT OF CONTACT (SPOC)
The SPOC acts as the focal point for management of corrective action system, initiating the
corrective action investigation when a SCAR (Supplier Request for Corrective action) is received.
The SPOC is responsible for final signoff of all reports and follow-up of CA completion status to the
customer. The SPOC is generally an individual trained in and responsible for the management of the
corrective action process and has knowledge of the business operations and key personnel.
The SPOC will identify and document the initial teaming structure within the business operation
and activate the appropriate team to respond to each SCAR. The SPOC is responsible for ensuring
that all team members have been trained in the CA/PCA process before becoming part of a working
team. Once teams have been identified, they will most likely work together on other similar
investigations.

IDENTIFY THE PROBLEM

The team members must understand and be able to clearly state the problem(s) in simple terms in
the form of a WHY question. Many events have more than one problem; identify and work them
separately. Ask the following to help formulate the WHY:

What is the problem to be resolved?

What is the customers concern?

Know your Problems!
You must understand the problem.
Is there more than one problem?
Keep it simple.

When writing an event or WHY question, remember the following rules:

An Event Question Is:

Short
Simple
Concise
Focused on one problem
Is a question starting with why?

An Event Question Does Not:

Tell what caused the event
State what to do next
Explain the event

Example: The Event: I didnt get to work on time.

Event-Related Question: Why was I late? (simple question)

If you cannot state it simply, you do not understand the problem.

10

GATHER AND VERIFY DATA

DATA GATHERING
The goal is to gather and document all the factual information necessary to ensure a thorough
Cause Analysis and data, which may be needed to complete any required reports. Normally, the team
may have to collect data several times during the analysis phase. The team will determine when more
data is need before they can factual answer the WHY questions and move on in the analysis phase.
Initial data gathering starts at the scene. Data has a shelf life; the longer you wait, the more
difficult it becomes to obtain good information. When possible, go to the scene and take note of who
was present, what is in place, when the event occurred, and where the event happened. If the event is
in the form of an audit finding, try to recover as much of the scene as possible.
Data Collection Tips

Location the site, building, facility, or field location where the event took place.

Names of Personnel operations personnel, visitors, contractors

Date and Time

Specifications what are the requirements?

Operational Conditions startup, shutdown, normal operations

Environmental Conditions noise levels, visual distractions, lighting, temperature,

humidity, weather, etc.

Communications verbal or written, what orders were being followed?

Sequence of Events in what order did things take place?

Equipment what was being operated?

Physical Evidence damaged equipment or parts, medical reports

Recent Changes in personnel, equipment or procedures

Training classroom, on-the-job training, none

Other Events have there been other similar occurrences?

The team must make sure that gathered data is correct and complete. Let the data tell the story.

Dont jump to a solution conclusion.

11

DATA VERIFICATION
It is vital that the team validates and verifies the data as it is being collected. Incorrect information
will impact decisions the team will make in respect to the corrective action chosen to implement; this
will manifest in the recurrence of a contributing cause. Look for the following:
Accuracy:

Was information copied from a document or from memory?

Were interviews done immediately after the event, or was there a lapse in time?

Second Source: Whenever possible, get confirmation from another source.

Conflicting Information: Note data that disagrees with other data. This can include data from
interviews/statements or documents/procedures. This could also include conflicting
interpretations.
Dont Be Afraid to Back Up: Your data may often show you that multiple problems exist. The
data may also require you to rewrite your event question.
Tools to Help in Organizing Data:

Create a process map. List the steps in the process and all of the associated variables.

Create a time line. Lay out each piece of data in its sequential order.

12

ANALYSIS

In the analysis phase, the collected data is evaluated to establish cause type. Team documentation
of this analysis is as important as collecting the data itself.

Docum ent
Causes

Determ ine Causes

Direct

Contributing

Root

13

DETERMINE
DETERMINE CCAUSE
AUSE

Why Did It Happen?

The cause analysis process requires complete honesty and no predetermined assumptions!

Eliminating preconceived notions is critical.

They cause the team to sidetrack the process.

They may lead the team to ignore data that points to the real problems.

Act on fact!

Follow the data, dont try to lead it.

This process is a tool to be used to obtain a permanent fix; you will not achieve it if you try to
force the analysis into supporting a preconceived corrective action.
Remember: Dont get personal; what we really want to know is:

NOT who did it, BUT Why did it happen?

14

THE WHY-WHY METHOD

Even the most serious or complex problems can be solved by using the WHY-WHY method,
coupled with cause chain diagrams.
Why?
Because the process is:

Fast

Informal

Natural to use

Universal

Effective.

Everyone, everyday, uses the WHY analysis method. Its a natural, logical progression for
thinking through a problem. The WHY approach provides a systematic process in determining all of
the contributors to a problem before implementing a corrective action plan. The WHY questioning
process is the center of the entire analysis phase. With each application, the user will gain proficiency
with where the questioning needs to go. This guide will establish some WHY basics. A presentation
of the 5 WHY analysis process has been added as an attachment to this guide to provide the reader
with a more in-depth discussion of the execution and application of this powerful tool.
CAUSE CHAINS
Cause chains are the product of the WHY questioning. Using a cause chain as a diagram allows
you to handle large or complex problems that are impossible for the human brain to see as a whole.
They also keep you honest!
Working from an effect back to a cause, restate the cause as a problem (Why?) and find the
next cause. Repeat until you run into success.
Keeping it simple is the secret to the process. Asking complex or poorly focused questions will
lead you off the correct path that will ultimately result in wasted time.

Take small steps!

Its very easy to jump ahead and leave out causes.
Simple Questions

Simple Answers

15

From the example below, you can begin to see how a chain of answers is derived from the WHY
questioning (simple question). The simple answers identify a cause, i.e., the cause chain. Each cause
(simple answer) leads to the last cause in a chain that is referred to as a root cause. As you will see,
cause chain can lead to multiple root causes.

Example of WHY-WHY Method of Questioning

Event: I didnt get to work on time.
Event-Related Question:

Why was I late? (simple question)

Car wouldnt start (simple answer)

Why didnt the car start? (simple question)

The Battery was dead. (simple answer)

Why was the battery dead? (simple question)

Dome light
was Big
on allSecret!
night. (simple answer)
The

Why was the light on? (simple question)

The car door was left open. (simple answer)

Why was the door open? (simple question)

Kids played in car. (simple answer)

Why were kids in car? (simple question)

Car not locked. (simple answer)

Why was car unlocked? (simple question)

Remote access failed to activate lock.

(simple answer)

16

What if you get two answers?

Cause chains like to branch a lot. Often this happens and you dont realize it right away. Study
each answer and if it contains two or more separate pieces of data you have identified a branch.
Continue the Why-Why questioning for both the original and new branch.
Why was the door open? (simple question)

The car was unlocked, so the kids played in the car. (not a simple answer)
Two pieces of data were given in the answer above:
Car unlocked and kids played in car.
Each becomes a branch that must be questioned.
Why was the door open? (simple question)

Car unlocked (simple answer)

Kids played in car (simple

Why was car not locked?

(simple question)

Why were kids playing in car?

(simple question)

What if you get two questions?

Youre going to quickly find out that asking the right question isnt always easy. Sometimes
there are two ways of looking at data, which leads you to form two different questions. Be sure
youre focused on that one cause and youre not jumping ahead. If your WHY questions directly lead
from the cause, then ask them. As in the example above, make another branch in the cause chain.

Solutions come later!

Stopping to consider solutions for each cause will mislead and slow the process. Not all causes
have solutions, nor do they necessarily need them. Build the cause chain first, then work on
the solutions!

17

Test the Chain

Prove the chain is correct by working it backwards. Began with the last answer and ask, Does it
follow that the last answer leads to the previous answer?
The Car Door Was Left Open
Did this cause?
Dome light was on all night.
Did this cause?
Battery was dead.
Did this cause?
Car wouldnt start
Did this cause?
Event: I didnt get to work on time.

In our example, did the kids leaving the car door open lead to not getting to work in time? Yes, it
did. Therefore, that step in the chain held up.
Cause Labels

WHY questioning, as seen in the example used, has produced what appears to be a satisfactory
chain. Cause labels need to be applied to the answers in the chain. Cause labels are categorized as
direct, contributing, and root. The following defines each of the cause categories and labels.
The first label in the chain direct cause:
The cause that directly resulted in an event identified the direct cause (The first cause in
the chain).
Event

Direct Cause

Car didnt start

The battery was dead

The direct cause is the answer to the first question (your problem statement). Jump-starting the
car will get you to work, but as it relates to this problem, it wont keep you from being late in
the future.

18

The next label is contributing cause: This is the cause(s) that contributed to an event, but by
itself would not have caused the event (the causes after the direct cause).
Event
Car didnt start

Direct Cause
The battery
was dead

Contributing Cause(s)
- Dome light was on all night
- The car door was left open
- Kids played in car

Note: For a simple problem, there may be no contributing cause; for a complex problem, there could be numerous
contributing causes.

The last label is root cause: It is the fundamental reason leading to an event, which, if corrected,
may prevent recurrence. Root cause doesnt hold any more or less weight than contributing cause; its
merely the last cause in the chain.
The root cause is really that point in a cause chain that is identified as the best place to stop. It
will become apparent to the team at some point that continuing the WHY questioning will not bring
any added value to the corrective action process in terms of cost savings. The root cause is not always
the most significant cause in the chain, and sometimes it cant be corrected easily or well. Focus on
the fact that it is just the last cause in the chain.
If we look back at the example of WHY questioning (page 20), the last item (remote failed to
activate lock) would be the root cause. Fixing the remote will not prevent recurrence 100 percent.
The remote operator or the remote may fail again so addressing one of the other contributing causes
may go further toward prevention like not allowing the kids to play in unlocked cars
Cherry picking the data to look for a root cause will lead to failure. Never try to build a cause
chain from the root cause backwards to justify your choice; youll end up trying to justify
assumptions or to serve an agenda. What you wont do is fix the problem!

19

How many root causes can there be?

As seen in the examples below, when a chain branches or an event drives more than one problem,
multiple root causes will result.
Example One When an event question drives an answer that identifies two or more problem
statements, each problem drives its own chain to a root cause.
Problem
One

Direct
Cause

Root
Cause

Problem
Tw o

Direct
Cause

Contributing
Cause

Event
Root
Cause

Example Two When a WHY question drives more than one answer, multiple contributing
causes can result.

Problem
One

Contributing
Cause

Direct
Cause

Root
Cause

Event
Contributing
Cause

Root
Cause

Contributing
Cause

Root
Cause

Where a cause chain branches into multiple contributing causes, each contributing cause points to
a problem that needs its own solution. Therefore, each branch of a chain must be worked down to a
root cause. Each branch needs to be analyzed to determine the significance of contribution to the
problem statement. In some cases, problems will be identified that dont directly impact the problem
under analysis but may be seen as an action that needs to be corrected and thereby worked separately.
The Risk Decision Guide (discussed on page 10) concept could be utilized to help evaluate
contributing causes to determine the extent to which to carry out a cause chain and corrective actions.
There may be instances where there is no root cause; this happens if the event chain trail becomes
lost or there is no more data. Records may be missing, required personnel are no longer present, or
the problem could be very old in nature. In these causes, you may have to call the last known
contributing cause as the root cause.

20

Review of Key Points in Process

Start with the event question. (identify the problem)

Use the WHY-WHY process. (gather data)

Take small steps dont skip causes. (do the analysis build the chain)

Write down each cause and the WHY. (simple question and answer)

No corrective actions allowed! (determine cause)

Test cause chain by working backwards. (validate)

The following is a simple example of cause application:

Direct cause = (D), the contributing cause = (C) and the root cause = (R).
Event: I didnt get to work on time.
Event-Related Question: Why was I late? (Simple Question)
Car wouldnt start. (Simple answer)
D

The battery was dead. (simple answer)

Dome light was on all night. (simple answer)

The car door was left open (simple answer)

Kids played in car. (simple answer)

Car not locked. (simple answer)

Remote access failed to activate lock. (simple answer)

Important Note: Some causes may not be directly related to the event but are still contributing to the cause and may point
out that there are additional problems to be analyzed (like kids played in car). Some problems may not have any
contributing causes between the direct and root cause.

21

Y-Y Curve

Normal progression of any analysis is to move from a point of not knowing enough about when
the event occurred (first target) to a point where the problem becomes well understood and workable
(bottom of the curve). Past that point, the problem picks up the silliness factor and quickly becomes
unworkable. Knowing where to stop takes practice, experience, and some assistance in defining the
limits of the root cause.
Ignorance

Silly

Car wouldnt start

Dome light was on all night

Unworkable
Car not locked

The car door was left open

The battery was dead

Workable

Kids played in car

Remote failed to activate lock

So when does the chain end?

Guideline rules for ending the chain:
4. Is the last cause within control of the team?
5. Does the team have ownership?
Utilizing the answers from the example WHY questioning from page 20, we can demonstrate the
guideline rules in the illustration above.
You must identify the root cause, even though you may not have the resources in your team to
solve it. Do not use these tests as an excuse to take an easy way out and not follow the process to the
root cause. Just because you feel a problem is beyond your personal ownership or that of the natural
team does not mean its beyond the ownership of someone or another team in the company. Actions
involving resources issues or issues outside of the team ownership must be elevated to management.
There are rare occasions when the root cause has been properly identified but has no solution. Its still
the root cause and needs to be documented.

The cause chain is your bridge between the event and the solution.
Trust it!

22

Building the bridge between an event and a solution requires finding the correct causes. You may
not be totally comfortable with the cause chains you have created; dont worry, the strength of the
process is that, as long as you have identified all the major causes, you are on your way to obtaining
valuable solutions.

23

SOLUTION

The solution phase is the culmination of all of the effort expended in the collection and analysis of
the collected data. It is at this point where corrective action of the identified problem takes place.
Dont be distracted with preconceived ideas or emotion-driven solutions like operator error. Let the
process point you in the right direction.

Determ ine Corrective Action

Specific

Preventive

M istake Proofing

24

Docum ent
Corrective
Action

DETERMINE CORRECTIVE ACTION

Corrective action solutions are defined as a set of planned activities (or actions) implemented for
the sole purpose of permanently resolving the problem. There are two types of corrective action,
specific (also known as immediate) and preventive (also known as sustaining). The following
discussion will expand on this concept of corrective actions taken during the CA/PCA process.
Specific or Immediate Corrective Action:
Action taken to correct the direct cause and change the effect.
Preventive or Sustaining Corrective Action:
Actions taken to prevent recurrence of the event that focuses on
the contributing causes and the root cause.
These two categories (specific and preventive) are quite different in how they are applied and how
these actions affect the corrective action process. Not understanding the importance of these elements
could lead to serious mistakes in fixing problems. Typically most corrective action stops with the
immediate corrective action and never gets to the more important preventive and mistake proofing
action steps. In other words we put out the fire but we never seem to get around to making sure that
the fire never starts again.
Lets take a look at the corrective actions and how they work.
SPECIFIC CORRECTIVE ACTIONS
Are actions taken to correct the effect and/or direct cause of an event. It can also be referred to as
specific corrective action. The action is immediate but does not prevent the event from recurring.

Specific action taken to change effect

Specific action taken to change direct cause.

Event = Late to work

Direct cause =

Specific action =

Effect = Car wont start

Dead battery

Jump battery

Immediate corrective action does not prevent recurrence!

25

Immediate Corrective Action

Immediate corrective actions are only used to correct the direct cause and change the effect;
theyre really a form of damage control and cleanup. The purpose is to limit or stop the effects from
getting any worse and repairing whatever was affected. Often, immediate corrective action occurs at
the scene in response to the event. When this happens, there may be nothing for the natural team to do
except document what was done.
Stopping a process until corrective actions can be applied is also a form of immediate corrective
action; it temporarily stops the direct cause from operating but does not provide an acceptable longterm solution.
The following is a simple example to illustrate immediate corrective action:
Event: Pilot holes were mislocated in parts.
Direct Cause: Drill fixture not to current configuration
Effect: Misallocated pilot holes in parts.
Immediate Corrective Action: Reject and rework tool. (direct cause)
Remake parts. (Effect).
The example shows two actions requiring immediate corrective action. One limits the direct cause
(reject and rework tool). The other fixes the effect (remake parts). The first action to the direct cause
does not prevent tooling configuration change process from allowing recurrence of the event.
It must be understood that correcting direct cause is only temporary. For example, in a
manufacturing process it can range from shutting down the process, changing the instructions, putting
a tool in bond, etc. Changing the effect can range from repairing damage tooling, fixing defective
parts, recalling material, etc., and is only temporary. These actions dont prevent the event from
recurring any time in the future.
Look for all of the effects. Often the problem has been occurring for a period of time before it is
ultimately discovered. The team needs to look at the history to find out if other like things, like
previously produced parts, are also part of the effect. Fixing or recalling delivered product is all
immediate corrective action.

26

PREVENTIVE CORRECTIVE ACTIONS

These are actions taken to prevent recurrence of the event by focusing on the contributing and
root causes. it is also referred to as sustaining corrective action.
Preventive
Corrective Actions

Contributing Cause

Root Cause

Preventive actions are focused on breaking the cause chain. A 100 percent fix at the root cause,
more often than not, will not prove to be effective if there are two or more not addressed contributing
causes in the chain, leaving it unbroken.
Determining the number of corrective actions to be taken and how effective they will be in
breaking the cause chain requires careful analysis by the team.
Contributing causes not directly leading to the root cause should be evaluated for corrections as
they may apply to other possible problems. A contributing cause missed or overlooked in the analysis
will also result in an unbroken chain and recurrence of the event.
Interim (temporary) corrective action of a contributing cause may also be implemented. This is a
special type of action that is effected to prevent an event from reoccurring until such time as
preventive corrective actions have been put into place. Interim corrective actions are used when it is
important to get a process back on line on a temporary basis. It can take the form of barriers that
block off an area or imposing corrective actions that would not be cost effective in the long run. If
interim corrective action is used, it must be reported with a deadline for final sustaining corrective
actions to be put into place. Remember, this is an exception to the normal corrective action process
and is not considered a standard step in the process.

27

Preventing recurrence means preventing recurrence everywhere!

How does a team handle contributing cause issues out of their area of control in order to break the
cause chain?

Expand the team, create a second team, or pass it up to management.

The team can handle most global issues merely by bringing in one or two more members that
have the authority to implement the corrective actions over a border scope of the business operation.

Do whatever it takes; just dont ignore the problem.

Doing the right thing means making prudent calls based upon facts.

28

Assessing Severity and Frequency of the Problem

Not all problems warrant the same level of attention. A typographical error that caused no harm
will not receive as much effort to correct as would a manufacturing error that causes thousands of
dollars in defective product. The team must look at the severity and frequency of the problem.
To assist in guiding this effort, ask the following three questions:

What is the cost of the event in terms of:

Personnel and environmental safety

Lost money
Lost time
Product loss
Customer dissatisfaction?

Schedule impact how likely is the event to recur if not fixed?

Can you accept the consequences of a recurrence?

If there are any doubts about the evaluation process outcome, or if the team needs assistance in
getting the corrective action approved, bring in a management representative as a qualified
team member.

Corrective Action Test

1. Do the corrective actions lower the risk of the
event recurrence to an acceptable level?
2. Are there adverse effects caused by implementing
the corrective actions that would make them
undesirable?
3. Do the interim corrective actions adequately lower the
risk of the event recurrence to an acceptable level until
preventive corrective actions can be implemented?

29

MISTAKE PROOFING
Mistake proofing is a way of thinking about corrective actions that gives you a much better
chance of developing fixes that are 100 percent effective. This is where most of your preventive
corrective action that prevents root cause from happening or recurring is identified.
Mistake proofing:
A process that provides a structure for designing
failure mode out of a product or process?

Mistake proofing devices and techniques are highly effective in breaking cause chains. They tend
to be simple, inexpensive devices that prevent errors from occurring or detect errors that have
occurred early enough to avoid serious risk. The point of mistake proofing is to keep errors from
becoming events that impact cost and/or safety.
To understand mistake proofing, you must understand the difference between errors and events!

Detected error occurrence becomes a cause.

Undetected error occurrence becomes an event.

30

Murphys Law suggests that defects are never found until after the final inspection. Mistake
proofing eliminates that law in that defects can be found before final inspection.

You have two options:

Option 1: Demand vigilance. There is no mistake, there has been no mistake, and there shall be
no mistake.
Option 2: Face reality and admit that Murphy was right. Inspection isnt 100 percent
effective. Use that knowledge to look at your processes in a new light to eliminate the error before
it becomes an event by mistake proofing. Change the way you look at operator errors. Remember
Dr. Demmings study on operator error? He showed that 94 percent of errors are process related
and only 6% are people related.

People make mistakes; rarely do they do it on purpose.

A process that requires a person to constantly make choices and decisions without much
guidance is primed for error.

31

The human brains default mode of operation is pattern recognition and autopilot execution. If the
pattern is familiar, a behavior that has been successful in the past will be launched. Its only when
feedback suggests that things are not progressing as planned that a more in-depth thought is brought
forth. As operators, we are on autopilot everyday until something happens to break us out of our
routine long enough for us to discover things arent functioning properly. A good process alerts the
operator when something is not being performed correctly. An operator will keep on making mistakes
until something tells them to stop. Thats where mistake proofing comes into play.

Keep in mind that a robust process will take into account varying
degrees of operator experience and be designed accordingly.
Use mistake proofing because:

Errors are more difficult to commit.

Its possible to reverse errors to undo them.

Its easier to discover errors that have occurred.

The process is more forgiving of errors.

So, how is mistake proofing done? Take a look at some everyday examples of mistake proofing
that is already in use in our daily lives:

The sneak a cup feature on coffee makers

Beepers on automated teller machines (ATMs) so you wont forget your card

Being unable to shift the transmission lever from park unless the brake pedal is depressed

Car lights that turn on and off automatically

Lockout fields and tab controls on electronic forms

Car wash that wont start unless car is positioned on the sensor pad

7-day pill dispensers

Kill switch on lawn mowers and treadmills

One-way-only part fixture setups (Poka-Yoke).

32

The three levels of mistake proofing are:

1. Source Detection A process where features and conditions are verified by
devices and techniques built directly into the work process. The process detects
the error, making it impossible to do the task incorrectly. Errors found at this
stage have not been passed on and therefore are not defects.
2. Self-Detection The process is structured so that errors are easily detected
during the operation. Operators can discover their own errors before passing
them on to become defects.
3. Successive Detection Occurring downstream from the error, later processes
are designed to be effective at discovering effects. Although this process
protects the customer, this level is not as effective or efficient as source
detection.
MISTAKE PROOFING THE CAUSE CHAIN
Error points are causes where someone failed to do something correctly a point at which a
mistake was made. As youve noticed in cause chains, there are always a few causes where you have
to ask if possible operator error caused the mistake and could have been discovered. These are the
causes you want to look initially to see if a mistake-proofing device can be used to prevent the event.
The distance between the error and the defect discovery is important to the process. It can have
implications regarding costs, missed schedule, or lost man-hours. It will also give clues as to where
corrective actions need to be applied to be the most effective.
Not all error points may have applicability for a mistake-proofing device, but the team should
continue to look at the rest of the cause chain.
MISTAKE PROOFING AND STATISTICAL PROCESS CONTROL (SPC)

Statistical process control relies on process mapping to capture and account for all the common
causes that produce process variations. Common causes are routine to the process such things as
tool wear, temperature variations, material lots, etc. The common causes are dealt with in a good
process design. SPC is then used to provide a measurement of process capability and warns of
variations.
Statistical process control is a form of defect detection. It happens after an error has become a
defect. The purpose of SPC is to detect special cause variations causes outside the process that
33

results in the process being out of control. Once their existence has been identified, SPC is unable to
identify how to prevent the special cause from recurring.
Cause analysis can be done to analyze the event and build a cause chain that leads back to the
special cause. The special causes are then eliminated by mistake proofing and are prevented from
recurring.
MISTAKE PROOFING AND FAILURE MODE AND EFFECTS ANALYSIS (FMEA)
Failure mode and effects analysis is performed to identify the potential failure modes in each step
of the process and the effects those failures would have on the product. It then ranks the order of
design and process deficiencies based on risk so you can focus on prevention of the highest-risk
problems. FMEA is a perfect match for mistake proofing.
FMEA Table
FAILURE MODE

EFFECT

CAUSE

CONTROLS

#1
#2
#3
#4

Expand the causes using

the 5 WHY process.

One WHY isnt enough

to uncover the causes for
high-risk effects.

34

Control
the
high-risk
modules with MP devices.

Things to watch out for in the process; common error-causing points

There are many types of operations or conditions that go against the human autopilot mode or
generally make conditions more stressful and therefore more prone for generation of errors. Think
hard about designing them out or using mistake proofing devices to protect the integrity of
the process.
Points to consider during the mistake proofing design process:
Adjustments Fixtures, tools, or designs that require the operator to tweak parts into alignment
Tooling Undetected tool wear, tool changes required between part runs
Points to consider (continued)

Lots of parts Many parts in an assembly process with similar sizes, shapes, or colors.

Lots of steps Assembly that requires many small operations where sequence of steps is
critical

No processing standard Where additional procedures, instructions, or training will be

needed to support the operation

Symmetry Where the symmetrical design of a part or mirror image layout makes it hard
to identify specific features or orientation

Asymmetry Where a part that is not symmetrical can be reversed and still fit

Speed and repetition Repeating the same operation continuously, requiring the
operation to be done quickly, or both

High volume Physical volume of product coming out of the process makes processing
errors more likely and detection of the errors more difficult

Environment Local conditions that can affect the process lighting, cleanliness, traffic,
temperature, etc.

Mistake proofing
The earlier its applied, the better.
Each stage of bringing a product to production needs to be accomplished with an awareness that
mistake-proofing devices should be implemented whenever possible. Product design allows you to
change design features to make it easier to build and make the processing less difficult. Process
design and development should focus on the operators interaction with the process and how to
reduce error points. Product/process validation is one last review in which trouble spots can be
spotted during pre-production build. Production may turn up more problems, identifying the cause
chain to implement effective mistake-proofing devices and allow for permanent corrections.

35

The cost of NOT mistake proofing

Mistake proofing is a very effective way to prevent errors from becoming defects. It works early
in the process and, as a result, costs less than other detection processes. Cost of nonconformance
increases in other defect detection processes the farther away the defect is noted from the point of
error. By the time a defect reaches final inspection or the customer, the cost is much greater.
Example: One prime contractor reported that half of their mistake-proofing devices cost less than
$100. However, the estimated net saving through their application was $8.4 million, or about $2,545
per device.

36

ASSESSMENT

In the assessment phase, proposed solutions are implemented. Responsible personnel are charged
with the oversight and verification follow up activity that determines the acceptability of the
implemented solutions. The Solutions and results are documented and issued as a report to the
customer.

Im plem ent and

Follow Up

Loop
Back

NO

Solution
Acceptable
?

37

Docum ent
Follow -Up

YES

Issue
Repot

IMPLEMENT AND FOLLOW UP

Proposed solutions do not become preventive corrective actions until they are implemented. To
implement, you have to know:

What, Who, and When

What is the corrective action?
Who is responsible for getting it done?
When is it going to be done?
Every corrective action listed should have the what, who, and when phase completed prior to
closing the action.

Dont make the big mistake!

Never assign a corrective action to someone who isnt on the team. Trying to do so means that
you missed one of your natural team members. Add the individual to the team, revisit the cause chain
and any proposed corrective actions prior to continuing with the implementation.

Do what you say!

Corrective actions must be accomplished as stated.

Its important to take things literally.

Did you accomplish everything as you stated in the report?

Were the tasks accomplished per the established timeline?

Dont commit to actions that the team cannot deliver.

Be careful in use of terms such as everyone or all; use of such terms implies your
certainty to deliver

Remember:

Say what you do.

Do what you say/

Be able to prove it.

Dont hang yourself with your report! Write your corrective actions clearly.

38

Start with who will follow up on corrective actions. The team isnt done until someone has
been chosen to look after the corrective actions. It doesnt have to be just one team member; a
problem with several corrective actions affecting different areas will involve different people.
Whoever is selected must buy into the process and the corrective actions.
Responsible team member needs to answer the following questions:

Were the corrective actions done as stated?

Were they done on time?

Have they been effective?

The answer to the effective question may not be obvious. The team should think about how the
effectiveness of the corrective actions could be tested or measured. What proof can be shown that the
problem has truly been prevented? How are you going to answer the customers concerns?
Did the corrective actions work?
If no:

Go back to the process.

Re-evaluate the cause chain.

Obtain the proper results.

Do it again.

If yes:

Youve closed the loop!!

What if questions reinforce the effectiveness of the corrective action:

The corrective action that was implemented is not what was proposed

Find out why not.

The proposed corrective action is not functioning.

Find out why and redo the cause analysis process.

Better or alternative corrective actions were applied.

They need to be reported.

The corrective actions were in response to an audit finding.

Not reporting the changes could set the stage for another finding.

The problem was serious, or you dont have complete control over implementing your
corrective action
Perform periodic checks to ensure that the corrective actions are still in place and
functioning. If possible, add this review phase to an already existing validation
process instead of creating a new review process.
39

ISSUE REPORT
Now that youve been through the entire data collection, analysis, solution, and assessment
elements of the CA/PCA process, its time to bring the whole thing together as a final report for final
approval. The team is not the only group that will review the documented effort; affected
management, organizations, and the customer may all review the teams results.
You may have done an excellent job of analysis and correction, but if the information is not
clearly written, no one will understand the results. Net effect: youve wasted your time.

BASICS OF A CORRECTIVE ACTION REPORT

Team Members: List the names of the natural and qualified team members.
Event Description: Describe the event that led to corrective action activities. If it was a
survey/audit finding, repeat the finding.
Event Question: This is a WHY question that the team used to define the problem being
analyzed and to start the cause chain.
Direct, Contributing, and Root Cause: Text blocks for the cause chain. Make sure to attach the
completed cause chain to the report.
Specific Corrective Action: Enter the action(s) taken to correct the direct cause and/or the effect.
This should include dates of completion and the names of owners.
Sustaining Corrective Action: Enter the actions taken against the root and contributing causes to
prevent the recurrence of the event, dates of completion, and names of the owners. List mistakeproofing devices and types implemented.
Team Signoff: Team members signify that the corrective action report is complete and ready for
presentation to management/customer.
SPOC Approval: Before the report is circulated to management and the customer, the SPOC
reviews the report to verify that the team has a product (reference attachment C).
The team and the SPOC should use attachments C and D to ensure that all customer requirements
are met in the report.

40

REFERENCES
Max Ammerman, Root Cause Analysis Handbook, New York Resources, 1998,
ISBN 0-527-76326-8.
Beauregard, M. R., Mikulak, R.J., and McDermott, R.E., The Basics of Mistake-Proofing, New York
Quality Resources, 1997.
Norman, D. A., The Design of Everyday Things, New York Doubleday, 1989.
Shingo, Shigeo, Zero Quality Control: Sources of Inspection and the Poka-yoke System, Productivity
Press, trans. A.P. Dillion, Portland, Oregon, 1986.
Kepner-Tregoe, Kepner-Tregors Problem Solving and Decision Making, United States Department
of Energy, trans., PRI, Warrendale, PA. 1982, DE-ACO4-76-DP00613.

41

ATTACHMENT A
USING WHYANALYSIS
Double click the button below to view a 23-page tutorial.
Tutorial

42

ATTACHMENT B
RISK DECISION GUIDE
This decision guide will help a team evaluate the extent to which a problem should be pursued
through the cause analysis and preventative corrective action process (CA/PCA). It will also help a
team to decide the extent to which to carry corrective actions and the amount of resources to be
applied to the corrective actions. The guide helps focus a business team on the implications and risk
identified from the business model. It provides a scientific way of determining the essential few
or most critical problems to be addressed by the CA/PCA process.
The risk factor or R calculation will identify the level of action and justification that should be
considered by a team. The R calculation is based on three elements: severity (S), frequency (F), and
detectability (D). The following provides a discussion of each of these elements and calculating the
risk factor.

SEVERITY RANKING (S)

Using Table 1 below, start by estimating how severe the effect of the problem or variation will be
for the next user or customer. This is the factor that represents the seriousness of variation in the eyes
of the next user or customer.
Table 1. Severity Ranking and Criteria
Rank

Severity Criteria

Unreasonable to expect that the minor nature of the failure would cause any noticeable
effect on the next operation. Customer will probably not be able to detect variation.

Variation causes only a slight customer annoyance. Customer will probably notice only
minor problems.

Customer is made uncomfortable or is annoyed by the problem. For example,

moderate rank would be given to undesirable attributes, such as the need for customer
to make revisions or corrections.

High degree of customer dissatisfaction due to the nature of the problem, such as an
unusable product or service.

Problem involves potential safety considerations or loss of customer.

43

FREQUENCY RANKING (F)

Next, using Table 2 below, estimate the likelihood that the problem or variation will occur.
Regardless of the risk factor calculated below, this frequency ranking is the best indicator of the
preventive capability (robustness) of the process. Corrective actions should be considered to reduce
high-frequency rankings even when the risk factor is otherwise within acceptable limits.
Table 2. Frequency Ranking and Criteria
Rank

Frequency Criteria

Remote probability of occurrence.

Low probability of occurrence (process in statistical control).

Moderate probability of occurrence. Associated with processes that have experienced

occasional failures, but not in major proportions (process in statistical control but not
quite capable).

High probability of occurrence. Generally associated with processes that have often
failed (process in statistical control but not capable).

Very high probability of occurrence, i.e., defect is almost certain to occur.

DETECTABILITY RANKING (D)

Finally, using Table 3 below, estimate the probability of passing a problem or variation on to the
next user or customer.
Table 3. Detectability Ranking and Criteria
RANK

DETECTABILITY CRITERIA

Remote likelihood that the product would be passed on or shipped containing that defect. The
defect is a functionally obvious characteristic that can readily be detected by a subsequent
operation. Detection reliability: at least 99.99%.

Low likelihood that the product would be passed on or shipped containing the defect. The defect
is an obvious characteristic. Detection reliability: at least 99.8%.

Moderate likelihood that the product would be passed on or shipped containing the defect. The
defect is an easily identified characteristic. Detection reliability: at least 98%.

High likelihood that the product would be passed on or shipped containing the defect. The
defect is a subtle characteristic. Detection reliability: greater than 90%.

Very high likelihood that the product would be passed on or shipped containing the defect. Item
is not checked or checkable. Defect is one that affects usefulness of product, is latent and would
not appear before shipping. Detection reliability: 90% or less.

44

Calculating the Risk Factor

The risk factor or R value is calculated by inserting the applicable ranking numbers (15)
selected from each of the three tables above into the following equation;

R = S2 x F x D
The resulting R value, when compared to the Table 4 below, identifies the risk factor and its
associated action level with justification.
R= Action Level
(R) Value

Action Level

Justification Criteria

0 to 24

None

Risk is acceptable. Do not have to complete CA/CPA process.

25 to 48

Minimal

Risk is acceptable if cost of preventive corrective action is

moderate to high (specific corrective action should be taken if
possible). Fix if cost is low.

49 to 96

Moderate

97 to 192

High

193 +

Very High

Risk is acceptable if cost of corrective action is high or

preventive barriers are put in place; otherwise fix.
Risk warrants considerable cost expenditure. Look for lowercost alternates if cost is prohibitive.
Risk is totally unacceptable. Fix at any cost.

Table 4.

A Supplier Corrective Action Request (SCAR) response, regardless of the action level
determined, must be provided to the initiator in accordance with the chapter on assessments. A SCAR
response for the action level of none will report the risk calculation, justification for each of the
ranking criteria selected, and justification for the action level obtained. Elaborate on the justification
criteria selected by stating why the risk is acceptable. Provide objective evidence supporting your
justification, including responsible management approval. The initiator reserves the right to require a
complete analysis and corrective action investigation if the justification is determined by the customer
not to be acceptable.

45

ATTACHMENT C
SCAR REVIEW AND APPROVAL GUIDE
The single points of contact (SPOCs) see these steps as the minimum required information and
action on a SCAR before he will approve it:
Team Members: Are all vested owners listed on the team?
Event Question: Does it starts with WHY? Check to make sure the question is the proper one
coming from the event description.
Causes: Are all causes, including sub-tier impact, listed? Causes must make sense when read in
order (forms a cause chain!). Test the chain by going backwards.
In Case of Operator Error as a Cause: Document the answers to the four questions. Improper
tools? Improper training? Improper instructions? Lost expectation?
Corrective Actions: Provide who (by name), what, and when for each action, even if it is already
complete. Include any subtier supplier involvement.

Specific CA: Must address the direct cause and/or effects.

Preventive CA: Must addresses contributing or root causes.

Does each CA have a corresponding cause on the chain?

Are mistake-proofing devices used and the types listed?
Did the team get buy-in from their management for corrective actions outside the teams
authority?
Outstanding CA must have a final due date entered in the follow-up panel.
Analysis of given defect against work in process, inventory, and product shipped or in shipping
cycle or in the field? If no other product was affected, state why.
Systemic Issues: Did the team identify and address them?
Professionally Written: Check for complete sentences, grammar, and punctuation. Readability
will it make sense to the customer?

46

ATTACHMENT D
SUPPLIER CORRECTIVE ACTION REQUEST (SCAR)
Issue Date:____/_____/____
Extension Date:____/___/____

Response Due Date:____/____/____

To Supplier Contact:

Supplier Code #:

Title:
Name:
From:
E-mail:

Address:

Phone:
FAX:
Subject Part # _____________

Rejection Tag Reference #__________________

Corrective action expectations and requirements:

Corrective action is required in accordance with Subsection 2.9 of the Supplier Quality Assurance
Requirements (SQAR) and this notification. Suppliers and their subtiers shall conduct an analysis to
establish cause and impact, determine corrective action, implement corrective action and follow-up to
validate effectiveness of implemented corrective actions.
Extensions:

Notification in writing (email is acceptable) is required within 48 hours prior to the due
date with justification.

As applicable provide revised CA completion dates, status of your investigation, and list
of the action taken and actions to be taken.

Guidelines:
To assist in clarification of terms and completion of the requirements stated above, cause analysis
and preventive corrective action guideline materials can be viewed on the OASIS Web Site
(http://oasis.northgrum.com). Northrop Grumman Integrated Systems encourages suppliers to study
and utilize these materials as they communicate the desired result of an effective corrective action
process. On-site assistance can be obtained by contacting your assigned Northrop Grumman
Integrated Systems Materiel Quality and Technical Services representative.

47

INSTRUCTIONS
A report containing the required report information, noted below, approved and signed by the
responsible supplier quality representative, must be submitted to the Northrop Grumman SCAR
initiator. Supporting documentation of the analysis and corrective actions must be included with the
report. Submit report to the initiator via fax or email on suppliers letterhead attached to the SCAR.
Required Report Information
The capture of all affected product and document status:

Work in process (WIP), include quantities

Stock/inventory, include quantities

Shipping cycle, include last ship date

Indicate conformance status of parts, i.e., suspect, nonconforming, or conforming.

Traceable part marking identifier applied to product (in accordance with SQAR 3.2).

Root Cause Analysis

Using a WHY analysis process, identify and document direct causes and contributing
causes leading to the root cause. This analysis must consider and document any like parts,
product, or processes that may also be affected.

NOTE: If you determine that the nonconformance is not your responsibility, respond to initiator with your analysis and all
appropriate supporting documentation.

Provide Immediate CA

Document the actions that will be taken to correct the direct cause. Include dates of
completion. Provide assurance that all affected product has been captured and the next
shipment has been flagged for 100 percent verification by your Quality Department prior
to shipment.

NOTE: Northrop Grumman Integrated Systems Inspection at your site is required to verify the immediate CA of product
scheduled for delivery prior to full implementation of corrective action. Platinum suppliers are not exempt.

Provide Preventative CA

Document actions that will be taken against the contributing causes to prevent recurrences
of the event. This action ensures that the correction of the event is applied to other parts,
product, or processes that are affected.

48

Required Report Information ( continued)

Implementation of CA

Document when implementation of immediate and preventative actions, respectively,

actually occur and what the results were.

Subtier Impact

When subtier involvement is identified, a subtier corrective action report shall meet all of
the aforementioned requirements and is to be included in the final report to Northrop
Grumman Integrated Systems.

CA Effectivity

Provide the date that culminates the actions of your Corrective action Plan and signals the
point at which the subject product or process will be ready for validation to confirm the
effectiveness of the CA.

Verification of Corrective Action (VCA)

Provide objective evidence of corrective action validation and effectiveness of

implemented corrective action. Include validation of subtier corrective action plans.
Submit records of verification to SCAR initiator.

NOTE: Northrop Grumman Integrated Systems may review objective evidence during a Verification of Corrective action
review at your site.

49