First, let me explain why I have written this article in English. Well, Strefa PMI is more and more recognizable. There are more and more foreigners working in our organization and I frequently receive comments that it is a shame that most articles are written in Polish. For the sake of my department mates, this one is going to be in English. The second reason is my laziness. My whole knowledge and experience in Project Management was gained in English so, frankly speaking, I am hardly able to translate all I know using proper Polish vocabulary.

Let’s start then with Risk Management as a crucial area for every PM. I would also dare to say that it is an area which distinguishes a good PM from “a common manager” who often gets into PM’s shoes for various reasons. He/she may feel proficient in business case, co-ordination or delegation, while risk management is then more or less neglected. I’ll give you a hint, as a person carrying out recruitment. If you are going for an interview for a PM role in a mature organization, be more than sure that this area will be thoroughly checked. With regret, I have to say that many of interviews showed that even experienced PMs have some difficulties with describing the process, they are not sure how to tailor it, or when quantitative analysis should be applied. Similar situation appears when project audits are carried out. Ask yourself and answer sincerely how good are you at managing risk? I would like to emphasize the word “managing”, so it is not only about identifying and performing some first process steps, but also further assessment of the risk, agreeing upon risk responses, identifying risk triggers and putting in place plans for you and your team to respond on risk, either to prevent/exploit or apply plans when a risk occurs and regularly control it.

So, what is Risk Management? Simply put, it is all about anticipation of what can go wrong in the project so that you may prevent it, or what in the project can happen positively to exploit it. Surprised? For those starting adventure with Project Management – yes, risks are also positive. They are called Opportunities and our job as PMs is to find the ways to materialize them if they can support success of our project in various axis. Do you need an example? Imagine that you are a PM transferring some technologies from one of the west EU locations to Poland. While sipping a beer with one of your friends, you have found out that you may obtain a grant from EU covering 50% of the costs of implementation of new technology. Normally, this technology would cost your company a fortune. Because in Poland your company may obtain the grant replacing one technology to another, your company could become the market leader and save additional operational cost after project implementation compared to a situation when you invested a comparable amount of money using existing old technology. Worth exploring and getting the interest of your stakeholders? Without a doubt. This is an example of positive risk you should manage as any other negative one. 

Coming back to the Risk Management as such, it is a process which have its inputs, processing steps and outputs. 


Do you have any in mind already? In general, they are all around you in the project environment. When you start a project, and further, when you are in the middle of it, or moving towards the end of it. To be more specific, when you start, obviously, it will be your Project Charter or any other mandate, if you use any methodology other than PMBOK based, Stakeholder Register and environment you work at. Furthermore, among others, it is your scope, estimates, management plans and outputs from monitoring and controlling processes. 

Steps of the process

Planning how you are going to approach risk management, identifying the risk, analyzing the risk (following PMBOK qualitatively and quantitatively), planning risk responses and, last but not least, controlling the risk. So let’s have some deeper insight in some of them. 


Usually, at the beginning of your PM carrier you google seeking some examples of risk register and feel great showing off to your boss how good you are. It especially concerns organizations where there are no PM processes built. But have you thought of things like who is responsible for what, how to organize your risks if you identify hundreds of them e.g. by streams, technology, org units, internal/external, what are the definitions of probability of occurrence or impact, what is the scale? Imagine that you ask your team member to analyze a risk. From his/her perspective, there is some risk which may cause not delivering his piece of work on time and he/she assesses the impact as 10 in 1-10 scale, while from your perspective you might realize that there are 3 alternatives within R&D project in parallel and delay in one of the streams does not affect your ultimate baseline much, so you would rather assess that as 5. So before you start acting like many of your “manager” colleagues do, think and plan what you are going to achieve and how you are going to execute and control it. Describe it to have a common ground, common criteria, guideline for your team and yourself. That is planning of risk management.


At this, I believe, you are the best from the whole process. I even assume that most of you do it with your teams and use logs from previous projects. There might be several articles written and several training sessions prepared about which technics to apply. The most common ones are brainstorming, interviewing your stakeholders (especially the key one), root cause analysis with Ishikawa in first row.


If you stop your risk identification on few points like risk of resource shortage, risk of power shortage, risk of delay on signature because your stakeholders are busy and not responsive, then you are probably asking yourself now, “what analysis”? I have it registered, written with some notes and now I need them all to be managed. If you, however, have done your job thoroughly, you have now hundreds of risks. In order to manage them properly, what you need to do at first place is to prioritize them. The most common technique is to apply Probability and Impact Matrix simply by multiplying what is the probability of occurrence by impact on your project. You are a PM, not a magician, so you cannot cope with all of them. Project is a change so, by definition, it is something uncertain and your job is to minimize the risks but you won’t be able to take care of them all. That means, however, that you will be able to manage them all because you’ll take conscious decision which to take care of first and how much attention attach to it and you may also change your approach when some other circumstances pop up. In risk analysis, Categorization is also important. It is made in association with some manageable categories. In social media, it is very popular to use #tagging so for fans of #tagging it will be easy to understand why we assign categories to risks. It is to link identified risk to some group you want to manage in bulk or just to find it in a simple way if, during execution, you find that it is important to review and re-assess particular group of risks. When analyzing a risk, do not forget to assign Risk Urgency. Some risks might be critical based on probability and impact analysis but potentially likely to occur in late future, while less critical risks may materialize very soon. Generalizing, that part of analysis is called Qualitative. In some cases you may identify a need for more thorough analysis, especially of the impact reflected in financial representation, impact of the risks on schedule, reserves, or analyze which option to choose by drawing a decision tree. Then we may start to speak about Quantitative risk analysis. The most well-known technics are EMV, Monte Carlo, Sensitivity Analysis with its Tornado diagram and Decision tree. A hint, if in your organization someone gave you a template with tens of fields for thorough financial analysis for every risk, including primary cost, cost of residual risk, etc., gently ask in a professional manner whether it is really needed. In many cases the templates were created by experienced PMs who were aware about the fact that, first of all, qualitative analysis should be done and only after that, a conscious decision is taken to select certain risks for quantitative analysis. Unfortunately, it may have happened that later the process is blindly copied to the procedures and executed as a requirement. 

Risk Responses

What are they? Simply put, they are reactions to risks that we have identified. We can:

  • Avoid: plan actions to eliminate the threat. For example, extend the scope by implementing 100% product control or, contrary to that, decrease the scope by getting rid of the risky requirement.
  • Mitigate: plan actions which decrease the probability of the threat, its impact or both of them. 
  • Transfer: make the other party responsible for the risk. It may be insurance, setting options for exchange rate and many others.
  • Accept: This is applicable both for threats and opportunities. What does it mean? You simply accept the fact that it may happen. It does not mean you reactively await it. You should prepare a Plan B, if the risk occurs. You apply this response usually when it is little or if there is no chance to prevent it (e.g. economic crisis) or when the cost of prevention would greatly exceed recovery plans when the risk occurs.
  • Exploit: plan actions to make sure the opportunity occurs. For example, hire a specialist for EU grant to gain cost recovery in the aforementioned example.
  • Enhance: increase the likelihood or the impact of the opportunity. 
  • Share: plan the actions to involve third parties to increase opportunity to bring the most expected results. For example, to create a joint-venture with local company being experienced on the local market or involve some technology experts increasing likelihood of the opportunity.


Now that we have identified, analyzed and elaborated risk responses, it is time to agree on where to store them and how they should be managed further. The place is a Risk Register which is an Output of the mentioned process steps. From my experience, there are 2 approaches to maintain a Risk Register. You are either obliged to use some company templates, and hopefully there will be plans created prior to that where you obtain some flexibility to work on it following certain criteria (see my hint above about filling in detailed financial information for every single risk), or you create/adapt your own template which will fit for purpose of your particular project. There might be various items stored in Risk Register. Is up to you and it comes with experience to know which are worth placing to find balance between workload to feed with information and workload to manage later. It is important to take conscious decisions. Some items might be manageable when stored in separate fields and some you just may put as a comment. From my experience, a very extensive document with tens of columns becomes less useful than a simple one. So decide on your own. Nevertheless, it is worth placing information about:

  • Risk owner and risk actionee – a person accountable and responsible. Good practice – never place generalities. If you need more than 1 person or info about department, then the second one should be placed in brackets but only one as primary.
  • Risk triggers – event, timeline or action when risk can occur to observe actively what is the risk status and implement action planned under risk response.
  • Contingency plans – the plans you put in action when the risk occurs.
  • Fallback plans – the plans to be brought to life if contingency plans would fail. We could call them plans C. The example is a roll-back plan to original state during IT migration.
  • There are also many other items like residual risk, secondary risks, references to other PM documents.

We have planned how we are going to approach risk management, we have identified and analyzed the risk and assigned risk responses. It would be useless if we do not start to control our risks. It is important to set ourselves a rigor to review the register, sort it out by urgency, follow up if planned action are being done, re-assess risks as they may become less severe, or contrary, increase their severity and likelihood. Guess what else? In an ongoing way, you also identify new risks and repeat the whole process over and over again. Do not leave it as an ad hoc action when time allows. Place it in your part of PM WBS. Book slots in your calendar. Do this exercise and, when asked, why you would like to book so many hours on a particular project certainly you can support yourself stating that X amount of hours you have booked for risk management. I bet that even a newbie would not claim that this is unnecessary.

Moving towards the end, you have either refreshed some basis or learnt some new stuff. If you start your adventure with Project Management, and I know that Strefa PMI is very popular among those who look forward to start a career as a PM, I have something for you to practice. Only then you would be able to show your experience during an interview. It might also be a good idea for every experience because if you are good at this in professional life, why not use this competence in private life? I benefit from 500+ program, so as you can imagine I have more than 1 little monster. This led me to move recently to the suburbs and I was faced with an entirely new situation. Initially, in our professional nomenclature, I have had many issues which I had to elaborate quick workarounds for. After I managed to implement them I started to anticipate what can happen to me and how to react. For some aspects I still have no good answers, some risks I already prevented from happening and others I managed to exploit. Sounds familiar? Yes, in your private life you can either practice or use professional competences to establish a Risk Register and perform risk management. I strongly recommend that to you. Here is an example, small extract which fits for my purpose but you may want to create either a simpler or more extensive one. 

Good luck with your Risk Management.