TRAINING

CAPA Management – Part 2

CAPA Management Part 2 – Continued from CAPA Management Part 1

Corrective Action Objective

To generate a plan of action that will that will eliminate or reduce the incidence of the root cause of the deviation, failure, or breakdown.

Developing the Corrective Action

Consider the following elements when preparing and documenting the corrective action plan
•Decide the means to implement the action
–SOPs
–Process changes
–Training or Retraining
–Implementation of automation or new equipment

Decide on the implementation time-frame
Determine the method of CA communication
Determine staff involved in carrying out the CA

Scope Of Corrective Action

Do not expand the corrective action beyond the identified root cause unless directly linked to another factor
The corrective action must match the root cause of the deviation.
If possible, build the corrective action upon existing or known barriers.
Remember that continuous correction is not quality improvement!

Effectiveness Evaluation

The objective of the Effectiveness Evaluation is to generate documentation that proves or disproves the following two statements:
The Corrective action was completed and implemented as planned
The corrective action was effective in the reduction or halt of recurring deviations.

Verify that corrective action was properly implemented
Determine data source for Effectiveness Evaluation
Determine when to perform Effectiveness Evaluation
Determine evaluation period
Consider impact of learning curve
Determine success criteria

Who Carries out the Effectiveness Review?

Operations management is responsible for the planning, completion and reporting of the effectiveness evaluation.
Reporting of the Effectiveness Evaluation consists of documented evidence of the effectiveness of the corrective actions taken for the event.

Timeframe for Evaluation

In most cases, the evaluation should be started no earlier than 30 days. This ensures that the staff is competent
and familiar with the corrective action submitted. Depending on the organizational SOP, the evaluation for
effectiveness should begin within 60 days of the corrective action plan implementation date.
Depending on the organizational SOP, the evaluation should be completed no later than 120 days after corrective action implementation.

Effectiveness Measurement

Observe staff directly involved in the execution of the corrective action alongside a small sample of other staff members (one to five) not directly involved in the corrective action.
Review source documents involved in the corrective action for one to three months post implementation. Look for omissions, corrections, or completion attributes that reflect a recurrence of the original deviation.

Staff may be interviewed individually or as a group to ensure understanding of the process
in question. Role playing exercises using corrective action scenarios may also be used
to ensure understanding.

Operations or Quality Assurance may perform a post corrective action audit to determine overall effectiveness.

Generate a presentation or internal document to ensure understanding of the process change initiated for the corrective action. Ensure that key stakeholders in the organization can articulate the problem. Run an update session with all teams and seek questions from team members about the issue and the investigation. If required make this memo part of the mandatory training for people affected. Supply a list of employees that have completed, including the date completed

For each effectiveness evaluation performed, a memo should be generated to document and summarize what was done for the evaluation and the resultant outcome.
Details including the date range, persons performing the operation, and specific root cause being evaluated should be documented in the memo.

In the Event of a Failed Evaluation

Issue a new deviation or nonconformity. The Root Cause Analysis will need to be redone.
Items to consider:
There may have been multiple root causes that were not initially discovered.
There may have been significant contributing factors that were not discovered.

To summarize an Effective CAPA Process

1. Define the problem.
2. Gather data/evidence.
3. Ask why and identify the causal relationships associated with the defined problem.
4. Identify which causes if removed or changed will prevent recurrence.
5. Identify effective solutions that prevent recurrence, are within your control, meet your goals and objectives and do not cause other problems.
6. Implement the recommendations.
7. Observe the recommended solutions to ensure effectiveness.

For more information Download our Troubleshooting and Investigation Guide here or contact us at info@systeme.ie

CAPA Management – Part 1

CAPA

CAPA (Corrective and Preventive Action) is a deviation management process that focuses on the systematic investigation of discrepancies, adverse events, or failures.

If used correctly, the CAPA process will provide a means to prevent the deviation from recurring.

How…?

•It provides a structured platform to conduct an
systematic investigation of the deviation.
•The investigation provides the means to develop a
permanent corrective action
•It provides a framework for documentation that the corrective actions are indeed effective.

Additionally, a CAPA system is the cornerstone of the organization’s Quality Management System (QMS).
21 CFR 1271.160(a) states:
General. If you are an establishment that performs any step in the manufacture of HCT/Ps, you must establish and maintain a quality program intended to prevent the introduction, transmission, or spread of communicable diseases through the manufacture and use of HCT/Ps. The quality program must be appropriate for the specific HCT/Ps manufactured and the manufacturing steps performed. The quality program must address all core CGTP requirements listed in §1271.150(b).

CORRECTIVE ACTION

An action taken to eliminate the root cause and symptom of an existing deviation or nonconformity to prevent recurrence

This is a REACTIVE action that eliminates problems identified in products, services, or processes and takes care of the immediate problem.

This is an action taken to eliminate the potential causes of a nonconformity, defect, or other undesirable situation in order to prevent occurrence.

Corrective Action

An Immediate Corrective Action is essentially a description of the steps taken to gain control of a situation or product immediately following the discovery of a deviation.
The immediate corrective action keeps the deviation’s scope from expanding. It also quickly resolves or corrects a discovered event, problem, or situation until the root cause is determined.

Products
–Quarantined
–Isolated
–Discarded

Equipment
–Removed from Service
–Replaced

Processes
–Manufacturing Suspended
–Test Results Withheld
–Recovery Procedure Halted

PREVENTIVE ACTION

This is a PROACTIVE action which avoids deviations through planned activities. It also eliminates or reduces the recurrence of the problem.

Steps in a CAPA Process

Discovery of the Deviation
Documentation of the Events
Immediate Corrective Action
Investigation of the Root Cause
Causal Analysis
Corrective Action
Effectiveness Evaluation

Means of Detection of a Deviation

–External Audits
–Internal Audits
–Staff Observation
–Performing a task
–Inspection or Testing
–Process and Equipment Monitoring
–Record Review
–Change Control
–Material Review Boards
–Complaints
–Adverse Events
–Product Returns or Recalls
–Notification by a customer or a client

Document the Deviation

The objective is to create a document that is an accurate, complete description of the event so that anyone can understand it.
–External Auditors
–Internal Auditors
–Technical Staff
–Administrative Staff

Essentially, the document should contain all the details needed, without the use of jargon.

To create a well documented and effective narrative avoid the use of subjective, fuzzy, or longwinded statements.

Other documentation considerations:

–If it isn’t documented, it didn’t happen
–If it isn’t documented, it doesn’t exist.
–Precise, economical word usage

In describing the facts of the deviation, include accurate descriptions of the following details:
–What was discovered?
–Who was involved?
–When did the event occur?
–Where did the deviation occur?
–How was the deviation discovered?
–How frequently does the process occur?

Root Cause Analysis Principles

•Understanding of how or why the deviation occurred.
•Understanding of the circumstances at the time of the deviation
•Determination of other products, processes, or individuals were involved
•Gathering of data to aid in the accurate future determination of a root cause and development of corrective action.

As Part of the Investigation you must perform

•Interviews of Staff, Customers, Suppliers
•Review of Policies, Procedures, Forms
•Records Review:

Training
Production
Equipment
Computer
Environmental
Security (Room Entry)

The high level objectives are to:

•Discover the primary (root) cause
•Result in recurrence prevention
•Reduce operational risks
•Improve operations
•Maintain quality and compliance

•The conclusions derived from a RCA must be the result of a systematic process which contains well documented evidence.
•Any given problem will have more than one root cause.
•To be effective, the RCA must establish all known causal relationships between the root causes and the defined problem.
•Performance improvement measures directed at root causes are more effective than treating the symptoms of a problem.

A thorough investigation will provide the needed information to establish the root cause.
The following questions are useful in gathering data during a Root Cause
Analysis (RCA).

–Who was involved in the deviation?
–What was the deviation?
–Where did the deviation occur?
–When did the deviation occur?
–How did it happen?
–How frequently does it happen?

The questions serve to capture the maximum amount of detail regarding the deviation or occurrence. They help provide data to understand why the deviation occurred.

The Root Cause Analysis is also aided by asking questions that relate to barriers to deviation.
–Describe any physical, organizational, or process barriers in place to detect deviations.
–Were the barriers were in place?
–What was their level of effectiveness?
–Describe any barrier failures.

Are there environmental problems?
Are the work conditions suitable?
Are there process flow problems?
Are there facilities problems?
Are there any equipment or materials problems?
Are instructions for use clear?
Are there problems with staff communication or staff training?
Is there adequate supervision?
Are there problems with the methods, SOPs, forms, or task analysis?
Do the steps performed match the operating procedures?
Has a process recently changed?

Use a Recongnized Method of Problem Solving

Consistent application of one or more of these problem solving tools along with the questions mentioned will provide a good platform to arrive at an accurate determination of root cause or causes.

•5 Whys
•FMEA
•Pareto Analysis
•Fishbone
•Causal Factor Tree Analysis
•Barrier / Change Analysis
•Task analysis
•Observation

For more information Download our Troubleshooting and Investigation Guide here or contact us at info@systeme.ie

Part 2 of CAPA Management coming soon………..

project management

5 Key Components of Project Delivery

Project Execution and Delivery

Weekly priorities and goals need to be set from the beginning. Set out a culture of delivery and accountability from the very start. On large projects – some team members can coast their way through the first few weeks of a project and before you know it – you are behind schedule. The success of a project is the result of the success of the day, week month and year of the project. Get the team members into the habit if self-accountability – i.e. where they tell the Project Manager what they will deliver today or this week and how this will contribute to the success of the project. This is where team selection is key – ensure that there are no passengers on the project team. People who are not contributing will suck the life and enthusiasm out of the project team and make the project harder to manage.

Utilize Project Team meetings a means of:

Communicating Status
Reviewing Performance
Making Plans for the coming week
Discussing risks and issues

This type of meeting should be held on at least a weekly basis depending on the level of activity and customer expectation. Rotate the chair, keep accurate list if minutes and follow up on actions regularly

Another function of this meeting is to gather information required for project governance to a site leadership or above site team. These updates are typically summary of the weekly project meetings. These meetings are also a means of highlighting issues and or requesting guidance and support at difference stages of the project.

At each major point in the project, e.g. after every big deliverable or milestone is complete – conduct a brief, honest review of performance, a lessons learned session to take forward any learnings into the next stage of the project.

Project Reports and Communication

Different organizations and industries will have their own requirements on the level and type of reporting and communication. There may be different templates to be managed depending on the level of reporting required. It can be useful here to only maintain a single reporting template for each project. The reporting template for each project should not become the focus of the work but should be used as a means for communication. On a project with a long duration, this can take a while to get right as the audience may vary and their weekly focus can shift from cost to schedule to risk to resources at a minute’s notice. The only recommendation here is to be honest, clear and transparent – the earlier an issue is highlighted, the earlier a resolution or support can be sought. Communication should always come from the Project Manager – and the PM should assign a delegate in the vent of absence. Stick to a consistent form of communication.

Project Issues and Resolutions

Throughout the course of any project -issues will occur. They can be technical, logistical, resource, risk, budget or schedule related. Instead of worrying about unknown unknowns – focus on what the strategy is for issue resolution. An example of this is:

1. Problem Statement
2. Probable causes
3. Impact to the Project – cost, schedule, risk
4. Conclusion or Root Cause – Where appropriate
5. Proposed Solutions
6. Recommendations
7. Support or Direction Required from Site Leadership or Above Site Teams via governance

Having a structure will help frame every problem and get the team into the habit of managing problems effectively.

Regular, honest and transparent monitoring of key performance indicators such as schedule, budget and scope will enable you to capture a potential issue before it becomes a bigger challenge to manage.

Managing Project Scope and Delivery

This is probably the biggest challenge facing project – the control of scope. The scope is agreed at the outset of the project via the Project Charter and other associated contractual documents. The detailed plan assembled before project kick off helps to clarify the definition of the scope further. With the best will and intentions – this scope will be misinterpreted somewhere along the way. Expect a dispute on one of the finer points of detail – this typically occurs when interfacing with a different system or having to manage another vendor or third party. In order to reduce the occurrence of such challenges always build risk around system interfaces and third party deliverables.

Another area where scope can increase or begin to creep is during “Corridor” or “Watercooler” conversations. i.e. someone may mention that – “It would be very useful to have a report on this new system that showed Purified Water usage on a Daily, Weekly and Monthly basis.” The statement may be true – but if is not in the original scope – it is not in scope. To some end users – statements made during conversations are a contract, an agreement by the project delivery person to include this requirement in scope and deliver it with the original scope of work.

Many organizations have procedures for Project Change Controls and managing extras. This may indeed be a legitimate business need but the original project costing and plan – it is not in scope. In order to include this requirement in scope the following must happen:

1. The end User or Client – Completes a project change request
2. This is assessed by the technical SME
3. An Impact report is produced in terms of Time, Cost, Risk
4. The end user accepts this proposal
5. The change in scope is approved at the Project Governance forum
6. The new requirement is included in scope and the original contract is amended accordingly.

Different organizations will have variations of this process but essentially the process must be respected.
There may be more simplistic examples were for the sake of good customer relations or lack of clarity in interpretation of requirements – a decision is made to absorb a change request into the original scope of the project particularly where the cost and time involved is negligible and will not impact the original delivery budget or schedule.

As a default position – it is always best to utilise the process that is in place as a starting point.

Project Closure

A common oversight in industry today is the effective and complete handover of a system and closure of a project so that all legal, financial and logistical obligations are discharged and recorded correctly to enable a project to close completely.

Before closure it is wise to conduct a review of project delivery against actual performance and original intentions. This can include the learnings carried forward from earlier stages. It is also important to acknowledge any challenges experienced and that you have implemented measures to ensure that a recurrence of the same issues is greatly reduced or eliminated. Items covered should be –

What worked well?
What needs improvement?
What should we start doing?
What should we stop doing?

If you happen to do business with the same customer or end user again – theresulting report is always a useful starting point.

Other items to be considered at project closure:

1. Any warranty obligations are have been honoured
2. A support agreement for operational support has been set up
3. All items within the project scope have been delivered
a. Documents
b. Procedures
c. Test Results
d. Training Evidence
e. Software Versions
4. All contractual obligations on both sides have been agreed and closed off

Project closure generally takes some time but this can be formalized with a meeting between all stakeholders to gain official agreement and consensus that the Project is now closed.

Need help?

If you are struggling to come to terms with repetitive project issues and you need some advice or support, contact us by email: info@systeme.ie with some background on your particular issue and we’ll be in touch.

Download our project rescue guide here Project Rescue Guide