Risk Management: Preventing Problems vs. risk register

Strange but true

• Absolutely all project and company management standards speak of the need for risk management. Various models, tools, and terms are available. Every PM understands that this is important. And undergo trainings. And they even try to carry out such practice (or process) as Risk Management. But not all (most) see this as meaning and benefit in practice. In the best case, risk registers (about which they will soon forget) are set up, in the worst they say that risk management takes place 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 projects, the company management believes that there is a lack of pro-active project management and communication with a customer who regularly complains about unexpected problems on the project.
• Project managers and project teams complain about the high time spent working with risks (and, obviously, the lack of effect, otherwise they would not complain.

These and many similar observations were made by me during the implementation of the quality management system and conducting process audits in IT companies. In particular, project management processes. Like any innovation, the implementation of work rules should be accompanied by a justification for why this is necessary. For this, in addition to persuasion skills, knowledge of theory and practical examples is needed - both negative and positive. My conclusions about the secrets of effective Risk Management are based on them.

Risks, sources of risks, 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 mainly encountered in project risk registers (generalized wording):

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

Gentlemen, these are the facts! To combat these facts, there are quality management standards (ISO), project management methodologies (e.g. SCRUM), work organization frameworks (PMBOK, CMMI), etc. They collect the experience of generations of managers and varying degrees of project success. They say that before signing the contract, it is necessary to stipulate the commitments of the parties (commitments), take care of the process’s human independence, create work artifacts (documentation and data obtained as a result of monitoring), etc. Think ahead about business continuity, in a word. But this is too "bureaucratic" and "out of date", according to many managers (especially "programmed" programmers, no offense will be said). We prefer to reinvent the wheel on each individual project, to extinguish fires, in general to hero.

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

Risk assessment

The Impact of this risk is determined by how large the deviation from the project goals will be, and how large deviations we can afford in relation to this goal.
It’s probably time to give an example. Isn't it more useful instead of the typical
" Source ": The
" Risk " command : A person can get sick
" Impact :" we won’t
have the following information in time :
" Source ": A person (A) who has tasks on the critical path has a pregnant wife who must give birth during a person’s (A) fulfillment of his tasks (this is a fact)
“ Risk ":
" The Impact :« possible deviation from the schedule by 20%.
The deviation from the schedule by 20% may be a trifle for one project (where 20% is 4 working hours and the time difference with the client 8:00 in our favor), but the real tragedy for another project (where 20% is 2 days and the client has a presentation with important stakeholders for a predetermined number). Given all these realities, the severity of the risk is assessed (for example, from 1 to 9, as in our company).

When we have decided on the consequences of risk, you need to think about its probability (Probability). The risk probability 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 to be absent. 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 effect on the probability. First of all, the task of the manager is to work with the most serious risks. Everyone understands this. Everyone also knows the basic strategies for responding to risk. Problems begin when you need to think about plans for responding to risk.

Risk Response Plans

Here are typical examples of a risk response plan that I come across:

• "Talk to customer"
• "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 Risk Management actions: 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 intent to prevent it.
Actions also have a cost (impact on the achievement of project goals: for example, human hours).
Only if there are 2 or more alternative scenarios, indicating their cost for the project (for example, one is reactive, i.e. after the risk is triggered, and the second is preventive if the risk response plan is included in the project plan initially and fulfilled), then we can decide what to do from this. Or provide an opportunity for management or a client to make a decision. Only in this case we manage (or take part in the management) of the project, justifying the title of 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, at risk with a person (A), the answer might be:
"To make it possible for the task to be performed by another person: a daily meeting on knowledge sharing with a second person (1 hour per day for the main character and 1 hour per day for “backup”). "
Cost of response to risk = 10 person hours per week, which is calculated on the schedule will be N% behind.
Compare with the possible deviation, if the risk occurs, take into account the probability of risk, and we go with that to the decision maker. The possible result will be a reduction in the amount of work or the adoption of one of the deviations by the client.

Number of Risks

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

• The register contains several (more than 2-3) dozens of risks, of varying degrees of detail. The manager takes a lot of time to review them, they are ultimately “slaughtered”.
• In the risk register there are about 5-7 risks, each of them is global and reflects not so much possible problems on the project as problems of the industry: technology, personnel management, etc. Moreover, the severity, strategy and response plan have already been indicated for them. They are periodically looked at with the goal of "not discovering the risk." There are at least two problems here:
  
  • Non-specific risk leads to non-specific response plans, the inability to effectively assess the impact of risk on project objectives
  • The reasons for reopening can be different, the potential damage is also different, respectively, and the response must be different at each reopening. T.O. these 5 “risks” are essentially sources of risks.
  
  
• There is no risk register. Risks are not documented. In the best case scenario, risks are discussed, assessed, and offer response actions, possibly even with an assessment of the response. In this case, the problems are as follows:
  
  • you can forget to do an analysis of whether the responses were effective
  • lose important lessons that could be applied once again, as a tool for "taming" the client.
  
  

The number of risks to be monitored should be as large as possible for those responsible for monitoring and responding to risks. Those. it is possible to record (and sometimes it is necessary) all identified risks, but to plan response measures is only for those whose influence on the goals of the project is really significant.
At the same time, if you had 10 risks this week and 10 last year, but it will most likely be at least partially different risks: the situation has changed, new circumstances have appeared, old ones have disappeared. But the sources of these risks may be the same.

That is, the whole point is the correct identification of risk. Correctly formulated risk will allow us to assess its impact on the objectives of the project, and therefore to select the most relevant and serious risks. Of course, if the goals of the project are also formulated correctly. But that is another topic.

Total

• The application 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, it is recommended to start not with the Risk Register, but with the following steps:
  
  • Clearly and correctly formulate (request) the goals of the project (accessible and understood by the person who is involved in risk management on the project, for example:
    “such and such users should be able to do such and such actions / receive such and such data with our application after 120 days "Errors in such requests are unacceptable."
  • Formulate specific and ultimate (SMART) Risk to achieve previously stated goals. To do this, determine:
    
    • its Source (a fact that - unlike risk - may be relevant throughout the entire project).
    • Look for sources in the Risk Categories that are relevant for several projects, organizations and the industry as a whole (for example: human resources management, a certain technology, the national culture of the customer, etc.)
    
    
• When working with risks, remember the following:
  
  • The purpose of risk assessment is the measurable potential impact of risk on project objectives; The purpose of the risk response is to change (measurably) the potential impact on project objectives.
  • Efficiency Management risk is determined by measurable indicators of how much potential deviations from the project objectives were prevented.
• And the last one. One often hears that - for various reasons - "it is impossible to manage risks on this project." But you are the manager!
  • Project Manager differs from Project Coordinator in that it takes part in developing the most optimal ways to achieve the goals of the project, including by finding potential problems (risks) in a timely manner and proposing alternative solutions.