Risk Management: Problem Prevention vs. risk register management

Strange but true

• Absolutely all standards of project management and companies talk about the need for risk management. Various models, tools and terms are offered. Every PM understands that this is important. And undergo training. And even try to carry out such a practice (or process) as Risk Management. But not all (most) see this as meaning and benefit in practice. In the best case, risk registers (which are soon forgotten), at worst, they say that risk management occurs in the course of daily communication (it is not clear, however, what is meant by risk and management.
• If there is a Risk register on the projects, the company's management believes that there is a lack of pro-active project management and communication with the customer, who regularly complains about unexpected problems on the project.
• Project managers and project teams complain about the time spent on working with risks (and, obviously, lack of effect, otherwise they wouldn’t complain).

These and many similar observations were made by me in the course of implementing a quality management system and auditing processes in an IT company. In particular, project management processes. As with any innovation, the introduction of work rules should be accompanied by a rationale for why this is needed. For this, in addition to the skills of persuasion, knowledge of the theory and practical examples, both negative and positive, is necessary. My conclusions about the secrets of effective Risk Management are based on them.

Risks, risk sources, risk categories

An analysis of the causes of inefficiency or lack of risk management in projects shows that people do not correctly identify risks and formulate a response plan.
Here are examples of typical risks that I mostly met in project risk registers (generalized formulations):

• "The client may not respond for a long time"
• “An employee may be absent from work suddenly”
• “The contract was signed without a thorough examination of the requirements”
• "There may be problems with the Internet"

Gentlemen, these are the facts! To combat these facts, there are standards for quality management (ISO), project management methodologies (such as SCRUM), frameworks for organizing work (PMBOK, CMMI), etc. They contain the experience of generations of managers and varying degrees of project success. They say that it is necessary to stipulate commitments of the parties before signing the contract, to take care of the human independence of the process, to create work artifacts (documentation and data obtained as a result of monitoring), etc. Consider business continuity issues in advance. But this is too “bureaucratic” and “inconsistent”, in the opinion of many managers (especially “managed” programmers, no offense will be said). We prefer to reinvent the wheel on every single project, to put out fires, in general, to be a hero. Such “risks” should be prevented at the preliminary planning stage of the project, preferably before signing the contract.

During the project, such unresolved problems become sources of risk. Regarding sources: typical sources of risks, documented in the risk registers that I observed - “Client”, “Team”, “environment”, etc. No one thinks about the fact that the source of a potential problem is not a generalized concept, but a certain situation is often negative)!
“Client”, “Team”, “environment” are the categories through which we look at the situation on a project and can find negative facts or situations that raise doubts about the achievement of project goals.
A certain negative situation (most often this deviation from the contract, from the work standards, caused by both an error and a conscious decision) may entail deviations from the desired (and planned) work results, that is, the goals of the project. This is already a project risk!

Risk assessment

The implications (Impact) of this risk are determined by how large the deviation from the project objectives will be, and by how large the deviations we can allow for this goal.
It's time to give an example. Would it be more useful instead of typical
" Source ": Team
" Risk ": A person can get sick
" Impact :" will not do in time
have the following information:
" Source ": A person (A) performing tasks on a critical path has a pregnant wife who must give birth to the person performing the tasks (A) (this is a fact)
“ Risk ": the above fact may result in the absence of a person (A) more than 3 working days (risk)
" Impact :" may deviate from the schedule by 20%.
Deviation from the schedule by 20% can be a trifle for one project (where 20% is 4 business hours and the time difference with the client is 8 hours in our favor), but the real tragedy for another project (where 20% is 2 days and the client has presentation with important stakeholders for a predetermined number). Considering all such realities, the seriousness of the risk is estimated (for example, from 1 to 9, as in our company).
')
When we have decided on the consequences of risk, it is necessary to think about its probability (Probability). The probability of a risk that a person may suddenly be absent from work is quite high, since there are several people on the project. Each of them may have several reasons for missing. But the absence of a well-defined person in a certain period may not be a problem, and the absence of another in the same period will be a tragedy. Here is another argument against generalized problems and in favor of specific risks.

The severity of risk - in the classics - is determined by the product of the consequences for the probability. First of all, the task of the manager to work with the most serious risks. Everyone understands this. They also know the basic risk response strategies. Problems begin when you need to think about risk response plans.

Risk response plans

Here are some typical examples of a risk response plan that I meet:

• "Talk to the client"
• "Do not let go on vacation"
• "Hold rallies"

Can we say how much risk will be reduced when applying these plans? That is, how effective are our actions on risk management: how much will the probability decrease? How much damage will be reduced?

A risk response plan is an action that should completely or partially remove a potential problem, but not a statement of the intention to prevent it.
Actions also have their value (impact on the achievement of project objectives: for example, man-hours).
Only in the case when there are 2 or more alternative scenarios, with an indication of their cost for the project (for example, one is reactive, that is, after the risk is triggered, and the second is preventive, if the risk response plan is included in the project plan initially and performed), then we can decide what to do from this. Or provide an opportunity for management or the client to make a decision. Only in this case we manage (or take part in the management) of the project, justifying the title of the Project Manager. By the way, this is a good way to earn respect in the eyes of the client, which leads to a decrease in pressure on his part.

For example, in a risk with a person (A), the answer might be:
" Make it possible to complete the task by another person: a daily rally on knowledge sharing with a second person (1 hour per day for the main actor and 1 hour per day for a backup)".
The cost of the risk response = 10 man-hours per week, which is recalculated to the schedule will be N% backlog.
We compare with the possible deviation, if the risk happens, we take into account the probability of risk, and we go with this all to the one who makes the decision. A possible result would be a reduction in the scope of work or the acceptance by the client of one of the deviations.

Number of Risks

One of the interesting questions is how much risk there can be on a project?
The logical answer is as much as you like, and the less organized the system and the less planned the project, the larger.
More specifically, the question should be: “How many risks do we need to control (document, monitor changes)”.
In practice, there are cases:

• In the register there are several (more than 2-3) dozens of risks, of varying degrees of detail. The manager takes a lot of time to revise them, they are eventually “slaughtered”.
• In the risk register there are about 5-7 risks, each of them is global and reflects not so much the possible problems on the project as the problems of the industry: technology, personnel management, etc. At the same time, for them the degree of seriousness, strategy and response plan are already indicated. They are periodically looked at with the aim of “not opening a risk.” There are at least two problems here:
  
  • Nonspecific risk leads to non-specific response plans, the inability to effectively assess the impact of risk on project objectives.
  • The reasons for re-discoveries can be different, the potential damage is also different, respectively, and the response should be different with each re-discovery. So These 5 “risks” are essentially sources of risk.
  
  
• There is no risk register. Risks are not documented. At best, risks are discussed, evaluated, and proposed responses, perhaps even with the evaluation of responses. In this case, the problems are as follows:
  
  • you can forget to do an analysis of whether the response was effective
  • lose important lessons that could be applied again as a tool to “tame” a client.
  
  

The number of risks that need to be monitored should be as it is possible for those responsible for monitoring and responding to risks to digest. Those. You can write down (and sometimes you need to) all identified risks, while planning response actions is only for those whose influence on the goals of the project is really significant.
At the same time, if you have 10 risks this week and 10 were last, but these are likely to be at least partially other risks: the situation has changed, new circumstances have appeared, the old ones have disappeared. But the sources of these risks may be the same.

That is, the whole thing in the correct identification of risk. Correctly formulated risk will allow assessing its impact on the objectives of the project and, therefore, selecting the most relevant and serious risks. Of course, if the project objectives are also formulated correctly. But that's another topic.

Total

• The use of risk management practices is not an end in itself, but a tool for:
  
  • simplify the life of the project team
  • effective communication with the customer and company management (that is, a tool used on a regular, daily basis) to achieve business goals (project goals).
  
  
• In order to get the most benefit with the least “extra” time spent, it is recommended to start not with the Risk Register, but with the following steps:
  
  • Clearly and correctly state (request) the objectives of the project (accessible and understood by the person involved in risk management on the project, for example:
    “Such and such users should be able to do such / such actions / receive such and such data with our application after 120 days. Errors in such and such requests are unacceptable. "
  • Formulate a specific and final (SMART) Risk to achieve previously defined goals. To do this, decide on:
    
    • its Source (a fact that - unlike risk - may be relevant throughout the entire project).
    • Sources look for categories of risks that are relevant to several projects, organizations and the industry as a whole (for example: human resource management, a certain technology, the national culture of the customer, etc.)
    
    
• When dealing with risks, remember the following:
  
  • The purpose of the risk assessment is the measurable potential impact of risk on the project objectives; The goal of the risk response is to change (measurable) the potential impact on the project objectives.
  • Effectiveness Risk management is determined by measurable indicators of how we managed to prevent potential deviations from the objectives of the project.
• And the last. We often hear that - for various reasons - “it is impossible to manage risks on this project”. But you are the Manager!
  • The Project Manager differs from the Project Coordinator in that it takes part in the development of the most optimal ways to achieve the objectives of the project, including by finding potential problems (risks) in time and proposing alternative solutions to them.