A bit of risk management theory

Risk Management Introduction

I decided to address the topic of risk management for several reasons:

• I recently developed a risk management methodology and procedure in a company where I work (custom software development, outsourcing) - respectively, a lot of materials were searched and studied, the information from which was then structured and framed into a separate document, which is now used
• risk management itself is one of the key activities on the project: in my opinion one of the most difficult, but at the same time interesting (you can benefit from every risk and event)
• As experience in software development companies shows, risk management is allocated either very little time, or they begin to be managed only when they become problems (which, you see, rather late). I hope that the information collected here will encourage those interested in further study of the topic and the introduction of relevant practices in their work.

However, it is worth remembering the following - risk management in any sphere of human activity, in my opinion, this is still only an applied discipline that provides general and practical recommendations.

Answers to all the questions in each specific situation will have to be searched independently - so you should not see in the risk management process any panacea for all ills, or an immediate and radical improvement in the development process. However, despite this, I consider risk management to be an indispensable part of a good project management process.

Risk determination

There are a lot of definitions of risks and all of them are, in principle, well known and intuitively understandable. I will give here only a few quotes I remember.
')
Risks are schedule delays and cost overruns waiting to happen (by Peter Kulik)
Risk is the possibility of suffering loss (SEI, Dorofee 96)

You should also understand the main difference between the concept of risk and the concept of problem:

• risk is some event that can happen in the future and can lead to certain losses (reduced product quality, budget overruns, delayed deadlines or a complete failure of the project)
• the problem is an event that has already happened. Risks become problems if you don’t work with them

Some terms and definitions

• Risk - some event or condition that can positively or negatively affect the outcome of the project (plan, quality, cost, volume of implemented functionality)
• Likelihood Risk - the probability that the risk will work. It is one of the attributes of risk and can be measured with integers from 1 to 4 (where 1 is a very low probability, 4 is a high probability)
• Impact of risk (Impact) - indicates the amount of positive or negative consequences for the project, if the risk is triggered. It is one of the risk attributes and can be measured with integers from 1 to 4 (where 1 is a small influence, 4 is a blocking influence). May also be called "loss"
• Risk Exposure - the product of probability and risk impact ( Risk Exposure = Likelihood x Impact )
• Mitigate (unfortunately, could not adequately translate) - develop strategies and action plans to reduce the likelihood and / or impact of risk to any acceptable level (for example, you can use a risk magnitude matrix, which will be discussed later)
• Mitigation strategy - an action plan aimed at reducing the likelihood and / or impact of risk to any acceptable level (risk mitigation plan)
• Contingency - an approach aimed at minimizing the impact of risk after it has worked
• Contingency plan - a plan aimed at reducing the impact of risk (the consequences of risk) after the risk has worked

It is necessary to distinguish the concepts of Mitigation and Contingency - the first relates to the risks, the second - to the problems. Implement mitigation plan - reduce or the likelihood or impact of risk when / if it comes; implement contingency plan - reduce the consequences of the risk that has already occurred.

For the same risk, both plans can be developed, but in most cases only one (here it is necessary to decide what is more important - to prevent the risk from triggering, or to minimize losses when it is triggered). Also, when developing a mitigation plan, people are often guided either by a mitigation strategy or only a risk mitigation strategy (which saves - why should one focus on reducing the influence of risk, if its probability decreases at the same time).

Risk management process

Below are the steps that I usually highlight in the risk management process.

• risk identification
• risk analysis
• risk planning
• risk resolution
• tracking and modification of risk data (parameters and / or plans and strategies)

Where to begin?

How does a risk management process begin on a project? According to theory - with the identification of risk (s) . It is necessary to compile a list of risks that would most fully reflect the picture of risks and potential problems on a project. It should be remembered, however, that even the largest list will never be complete - something will always be missed. ;)

Analysis

The result of this stage is a qualitative and quantitative risk assessment, which can be carried out in the following areas:

• Risk Assessment - Determining Attribute Values ​​Likelihood (Likelihood) and Impact Risk
• risk classification - a grouping of risks based on any characteristics (for example, by the type of risk they can be divided into "Quality", "Management", "Hardware", "Software", etc.)
• risk prioritization - prioritization. Practically, prioritization is done on the basis of the risk magnitude matrix, which I mentioned above.

Likelihood \ Impact	Small = 1	Medium = 2	Critical = 3	Blocking = 4
Very likely = 4	four	eight	12	sixteen
High = 3	3	6	9	12
Medium = 2	2	four	6	eight
Very low probability = 1	one	2	3	four

With this definition, the amount of risk is the easiest way to determine a quantitative characteristic of risk. In practice, it makes sense to monitor and manage risks that are on or above the main diagonal of a given matrix (that is, with risk values ​​greater than or equal to 4 or 6).

After analyzing the risk, we can create the top 10 risks (Top 10 Risk List), plotting the risks in descending order of risk magnitude and selecting the first ten. It should be remembered that choosing a greater number of risks can turn risk management into a very difficult process that will be too expensive and inefficient.

Planning

The main task of planning is to answer the question of how we will handle each of the risks. Here are the following options:

• risk research (research) - conducting further risk research for its detailed elaboration and more accurate planning
• accept risk - we accept risk and are ready to live with its consequences
• risk avoidance (avoid) - we assume that risk will never become a reality
• risk transfer (transfer) - transfer of risk and responsibility for it to another team, to another manager (possibly to the company’s management), to another person

Directly for risk management, a mitigation strategy (actions that we take to reduce the likelihood and / or impact of risk to an acceptable level if we choose this strategy) and a contigency plan (action plan in case the risk has worked) should be developed.

Risk mitigation

At this stage, the risk is actually resolved after it has been triggered. That is, an appropriate contingency plan is being executed. The task of the stage is to perform it in the most efficient way, and also to collect and analyze information about this risk for the next stage.

Tracking and modification of risk data

The following objectives are pursued at this stage:

• risk status monitoring
• status monitoring mitigation strategy and contingency plan
• monitoring project metrics that are related to action plans
• identify and notify all interested parties that the trigger of a plan of action has triggered

Since the situation on the project is constantly changing, it is necessary to constantly monitor changes in risk parameters, adjusting the “Top 10 Risk List”:

• identification of new risks that were not considered before
• change in quantitative risk assessments (return to the analysis stage, the Top 10 Risk List may change significantly)
• determining whether the change in quantitative assessments (if any) resulted from the implementation of certain action plans (mitigation strategy or contingency plan). If the magnitude of the risk decreases, then most likely the mitigation strategy is implemented successfully, but you shouldn’t be seriously deceived about it.
• determination of methods and methods of correction of action plans with due account of certain changes; transition to planning

Conclusion

The key point of the risk management process should be the periodic repetition of these processes, preferably consistent with the duration of development cycles and workflows. We can recommend a risk assessment once every 1-2 weeks, depending on the size of the project (in some very large projects, the frequency can be increased up to a month, but I wouldn’t do more).
I also want to recommend keeping a history of changes in the list of risks and their parameters (at least the Top 10 Risk List) - in the future this will give us the necessary statistical data.

P.S

It should be noted that the information above is a squeeze out of a large, official and extremely formalized risk management procedure that I created for the company in which I work. Some formal steps (for example, risk management planning, control) are omitted, for the steps outlined, a description of their essence is given, which helps to understand them, but leaves a certain freedom of choice and flexibility in applying to various projects.

However, it is possible to designate ways for the further development of the article.

• detail stages (input and output documents, key activities and responsibilities of the performers)
• proposals for the format of documents that can be used in the process
• discussion of the most common risks and strategies for their resolution (the so-called Risk Assessment document)

I invite all interested parties to talk on this interesting topic;)

useful links

MSF Risk Management Discipline v.1.1 - www.microsoft.com/downloads/details.aspx?FamilyID=6c2f2c7e-ddbd-448c-a218-074d88240942&displaylang=en (http://www.microsoft.com/Rus/Download.aspx? file = / Msdn / Msf / MSF_risks_mngt_rus.doc)

'Continuous Risk Management at NASA' - satc.gsfc.nasa.gov/support/ASM_FEB99/crm_at_nasa.html
PMBok - www.pmi.org/Marketplace/Pages/ProductDetail.aspx?GMProduct=00100035801

Risk Management @ SEI - www.sei.cmu.edu/risk

SWEBOK (Guide to the SoftWare Engineering Body Of Knowledge) 2004 (Iron Man) - www.swebok.org

Just interesting sketches for project management - jchyip.blogspot.com/2008/12/lean-it-in-sketches.html