4 Steps to Risk Analysis & Management

How many of you grimace when you see the appointment in your diary for a risk analysis review meeting? Have we forgotten how useful this should really be? Are we also afraid to take risks? Without some risk, we cant push the boundaries out.

Why has this happened and more importantly, what can we do about it. Risk analysis should be equivalent to putting on a bullet proof jacket in combat – it is there for our protection and conducted properly adds real value to our projects. The reason why we should utilise it to remove or reduce the risks which threaten our project success.

So what framework do we have for Risk Analysis and Management?

I am suggesting that we take a 4 Step Process and apply it always and from the very outset (feasibility) of our project. The 4 steps are:

1. Risk Identification

2. Risk Analysis

3. Risk Response Plan

4. Risk Monitoring and Control

So let’s start at the beginning

You have just taken over on a new project and are busy, busy, busy. You believe that the key is to get the scope nailed down, the team built and the funding secured – we will take a look at risks later on – they are not really that important, because this is essentially the same as a project we did last year, but bigger and with more aggressive delivery dates.

That is a lot of assumption – if they are all TRUE, then you are in the clear; if any of them are FALSE, then you are ignoring potentially fatal risks – russian roulette comes to mind.

Apart from that, risk identification is going to influence how (and possibly what) you choose to execute the project and will also possibly influence your calculation of required contingency requirements.

So let’s start with “Risk Identification”.

In order to address this properly we need to define “What” the activity is and “How” we will execute it.

Let’s start with the WHAT
The key objective of this stage is to capture any risk/problems which might occur during the delivery of the project objectives which may impact our chances of success.

The HOW is a little bit more detailed
Here we will need to have some brainstorming sessions with the client and key technical resources so that we can evaluate the type of things that might happen, how likely they are to happen and finally, what the impact of such an event would be.
So let’s take a look at a framework that would allow us to analyze and manage the risks for our project from the outset – let’s call it the Kevlar Jacket Approach.

Step 1 – Risk Identification

As stated above, to aid in identifying the risk, we first need to identify the right people to aid us in this – technical experts, customer, project manager. Once we have identified the right team, we then need to conduct the risk analysis – here we need to use a mix of:

1. One on one meetings

2. Brainstorming meetings

3. Review of previous project risk and issue registers

Risk Identification

During these activities we need to capture key information to allow us to analyze, respond and manage these risk. During the identification step, make sure that you capture the following:

1. Give each risk a unique identifier – a simple number from 1 to n.

2. A risk description which is sufficiently detailed enough for anyone reading the risk register to understand the risk or ask intelligent questions of the person who identified the risk.

3. A risk indicator – i.e. any event which might be an early warning sign of the risk occurring, or may trigger a sequence of events that if not controlled properly would lead to the risk occurring.

4. Categorise the risks into specific buckets – e.g. Safety, technical, commercial etc..

5. Record who identified the risk, on what date

6. Record during what activity was it captured – e.g. brainstorming session, 1 on 1 interview – this will be useful for analysis across projects and will help you continuously improve your risk analysis process.

So that then covers the information you need to capture once you have identified a specific risk. The next step is to analyse it and get a detailed understanding of what its occurrence would mean.

Step 2 – Risk Analysis

Once you have identified a risk you need to analyze it – you need to once again ensure that you have all the right people present to conduct this in a meaningful way.

Risk Analysis

The key activities here are:

1. Get an understanding of the impact to the project/business if the risk did in fact materialise – this will require key input from the customer and the technical experts.

2. Rank this in terms of significance, using a scoring system of 1 to 5, where 0 = none, 1 = low and 5 = very high – make sure that this is discussed in detail and there is a reasoned basis for the score.

3. Gain an understanding of the probability of this event occurring and rank this in terms of probability, using a scoring system of 1 to 5, where 0 = none, 1 = low and 5 = very high – make sure that this is discussed in detail and there is a reasoned basis for the score.

4. Now calculate a Risk Score = Significance x Probability

5. Colour code the risk based on score – define Red, Yellow and Green bands e.g. 0-5 = Green, 6-12 = Yellow, >12 = Red.

Now we have some useful information to go forward with – the next step is to build a plan to either reduce the impact or eliminate the opportunity for it to occur. We are now in the realm of managing our risks and we must build a risk response plan – our next step.

Step 3 – Risk Response Plan

Here we start to look at how we manage the risk we have identified – we have 4 main strategies that we can use, and we are going to call the them 4 T’s.

Risk Response

The 4 T’s

1. Terminate (often referred to as Avoidance)

2. Transfer

3. Treat (oftener referred to as Mitigate)

4. Tolerate

So, let’s look at each of these individually.

Terminate is where specific steps are taken to ensure that the risk is eliminated (avoided) or that the impact it had is prevented.

Transfer is where the risk is passed to another party; the weakness with this is that the risk does not go away, it’s just causes someone else a problem.

Treat is where by taking certain actions immediately, the risks can be reduced.

Tolerate is what it says and the reason we tolerate them is that despite the fact that we cant do much to reduce or eliminate them, the benefits of taking them far outweigh the penalties/cost.

Step 4 – Risk Monitoring and Control

This is the routine part and requires the project manager to be diligent and monitor the status of the risk, the residual score by reassessing the risk at critical junctures and the risk state – is it static increasing or declining. This is a key activity and depending on the trend and significance may require a renewed effort by the project team to ensure that identified risks are dealt with appropriately.

Risk Monitoring

Finally, the housekeeping. Put all of this information in one central location – A risk register. Make sure that all key stakeholders are informed on this and agree with your plan of action.

Would love to hear your comments and am delighted to answer any questions you might have.

0
shares

  • Dishant Sanghavi

    Can you give one example of 4 Steps to Risk Analysis & Management ?

    Dishant Sanghavi

  • Dishant Sanghavi

    Can you give one example of 4 Steps to Risk Analysis & Management ?

    Dishant Sanghavi

  • chandra

    Very nice article, thank you sir

  • chandra

    Very nice article, thank you sir

  • JIm Lehane

    Good article William. Worth emphasing that you MUST have the right blend of experience at the Risk review, and you must push the boundaries to try discover the ”unknown risks”.

    Jim.

  • JIm Lehane

    Good article William. Worth emphasing that you MUST have the right blend of experience at the Risk review, and you must push the boundaries to try discover the ”unknown risks”.

    Jim.

  • Cleach

    When should risk management be applied? At a contract lab we do not manufacture, only work on projects from other companies. When would it be important to apply a risk analysis?

  • Cleach

    When should risk management be applied? At a contract lab we do not manufacture, only work on projects from other companies. When would it be important to apply a risk analysis?

  • Toni J. Fernandez

    It would also be very useful to me if a real-life example could be provided using the process. A GxP computer system validation project example would be particularly useful to me, especially with regards to how to apply risk analysis and management to the level of validation required for the project.
    Thank you.
    Toni

  • Toni J. Fernandez

    It would also be very useful to me if a real-life example could be provided using the process. A GxP computer system validation project example would be particularly useful to me, especially with regards to how to apply risk analysis and management to the level of validation required for the project.
    Thank you.
    Toni

  • ravindra singh

    hello it is nice but i need to know more deep about this actualy it is the only outer parameter but the time of incident it is not sufficiant.

  • ravindra singh

    hello it is nice but i need to know more deep about this actualy it is the only outer parameter but the time of incident it is not sufficiant.

  • Jay Naidoo

    Nice framework to work with. What risk score would you consider as being appropriate when developing a risk plan?

    Also, the use risk based approach requires buy-in from all stakeholders ie. Top management, clients. Often deleloping a risk plan may involve additional resources and time which impacts on the target date of the project.

  • Jay Naidoo

    Nice framework to work with. What risk score would you consider as being appropriate when developing a risk plan?

    Also, the use risk based approach requires buy-in from all stakeholders ie. Top management, clients. Often deleloping a risk plan may involve additional resources and time which impacts on the target date of the project.

  • Abdul Rauf

    INFORMATIVE ARTICLE

  • Abdul Rauf

    INFORMATIVE ARTICLE

  • Srikanth

    Good and refreshing article.Clarity at each step provides better understanding of the topic

  • Srikanth

    Good and refreshing article.Clarity at each step provides better understanding of the topic

Similar articles:

An Alternative View of the ICH Q10 Pharmaceutical Quality System (PQS)

The image below is that depicted by the International Conference of Harmonisation (ICH) Q10, Annex 2, and is supposed to depict a PQS or Pharmaceutical Quality System.

Typically, I really love the ICH. When we have to deal with outdated regulations from different global organizations it becomes a real nightmare trying to keep track of the nuances and the ICH has done a pretty good job of bringing several of the key organizations together and aligning them on how best to organize and meet the expected requirements.

That being said the diagram below and the depiction in Q10 of what a PQS should look like is greatly lacking.

Development Phases

In section 1.8 under the Quality Manual the ICH Q10 guidance states, “The description of the PQS should include: …(c) Identification of the pharmaceutical quality system processes, as well as their sequences, linkages and interdependencies.

Process maps and flow charts can be useful tools to facilitate depicting the pharmaceutical quality system processes in a visual manner”.

I completely agree.

The problem is using the graphical depiction they present in Annex 2 is completely worthless.

Basically they listed some of the PQS elements in a bar and then said they all apply to the entire product lifecycle, which simply isn’t true.

When we are in the development phase of our product lifecycle why would we do that under the change management system, or monitor process performance?

 

Controlling Change – No Value Add

There is no point in controlling changes for a product that is purposely being changed, nor does it offer any value to monitor the process performance for a process that has yet to be developed.

This isn’t a graphic depiction of the PQS, but rather a graphic of how they depict the lifecycle management (which also has some issues).

The PQS is the quality system and its subsystems and how they interrelate.

While it’s useful to look at how the PQS and product Lifecycle Management overlap and what elements of the PQS system are relevant at each lifecycle stage, it is not the point of the PQS, and even if that’s the end goal it’s not depicted here at all.

This image offers almost no value.

A Better Approach

So, what should this graphic look like?

While this is not a perfect view of a PQS, I would propose that the image below is a much better depiction of how the PQS should be visualized and a good place to start.

At the core of any quality system should be management. This goes back to Deming, who said, “Quality begins with the intent that is fixed by Management”.

Quality has to be rooted in the executive management team.

Define Core Quality Systems

Core quality systems then need to be defined. These are systems that impact all aspects of the business and include a Risk Management Policy, Resource Management, Document Control and CAPA systems.

All of the other subsystems, Deviations, Supplier Management, Equipment Qualifications, Validation, Material Management, etc, etc. all should be risk based or involve risk assessment, they all require resources and training, they call require documents (procedures, policies, records), and the CAPA system of course drives for process improvement regardless of the process.

Subsystems

All subsystems feed back into the main Management module. The subsystems listed, all are interconnected, with the exception of Post Market Systems.

The subsystems are important too, but they are farmed out to different groups and have different levels of importance depending on the stage of the product lifecycle.

Post Market Systems

The one exception is the Post Market Systems. This includes complaint management, product reviews, recall processes and other systems to support marketed products.

These generally do not interact with the other subsystems unless it is through the CAPA system or other management functions, but still utilizes all the systems under the management umbrella.

Alternate View

The PQS presented here, isn’t intended to be perfect, but I thought it was worth presenting an alternate view to the one presented by the ICH.

The ICH concept is a good one, and the ideas are fairly well laid out in the ICH, but the graphical representation of the PQS leaves a lot to be desired.

When establishing a PQS, it is better to start with something to what we’ve depicted here, and customize it as needed for the organization.

8
shares

Similar articles:

How 21 CFR Part 11.3(7) Applies to Electronic Batch Records [Video]

When dealing with Part 11 it’s important to understand what an electronic signature actually means

The definition of electronic signatures or e-sigs can be found in 21 CFR Part 11.3(7).

Electronic Signature

An electronic signature or e-sig means a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual’s handwritten signature.

Handwritten Signatures

We also need to understand what a handwritten signature means in the context of Part 11.
The definition of handwritten signatures can be found in 21 CFR Part 11.3(8).

Handwritten signature means the scripted name or legal mark of an individual handwritten by that individual and executed or adopted with the present intention to authenticate a writing in a permanent form.

The act of signing with a writing or marking instrument such as a pen or stylus is preserved. The scripted name or legal mark, while conventionally applied to paper, may also be applied to other devices that capture the name or mark.

Electronic Batch Records

Eric works in a Pharmaceutical company and he is responsible for the filling process of the batch been manufactured.

Each time Eric performs the filling process he has to populate a batch record with the appropriate details

After each step Eric must also fill in his signature and date to verify that he actually performed each task.

Eric is manually handwriting these details and they are legally binding to Eric.

21 CFR Part 11.3(8)

This is when 21 CFR Part 11.3(8) applies.

Fast forward 12 months and Eric’s company has implemented a brand new Manufacturing Execution System (MES) where all details around the batch manufacturing process are recorded electronically.

21 CFR Part 11.3(7)

Now when Eric performs the filling process he now populates everything electronically and signs with his username and password combination to verify that he has performed those tasks.

This is when 21 CFR Part 11.3 (7) applies.

0
shares

TOP

Similar articles: