Project managers are always striving to learn new knowledge and master a lot of useful skills, be successful, and keep up with innovation. In project management, there are must-have disciplines and areas where managers need to ensure the successful operation of projects and releases without risks. Today companies of different sizes and industries choose to have a specialized structure responsible for the quality and success of projects – the Project Management Office (PMO).
One of the major functions of the PMO is risk management, and the larger the company, the more important it is for the company’s success and even its survival. The company’s Project Management Office always needs to “keep abreast” and timely diagnose the danger to the projects. It is important to pay attention to details and constantly engage in the analysis of the situation and processes in terms of existing and possible hazards including:
- Project risk management
- Risk management planning
- Risk identification
- Qualitative risk analysis
- Risk response planning
- Risk monitoring and control
For these purposes, we created PPM Insights – a special module of PPM Express which makes it possible to perform the proactive analysis of the situation on the projects, and track issues and inconsistencies whether it is late milestones, budget overruns, or resource overloads. Depending on your license, you can either have a single dashboard where you can see all the issues on one screen and have an everyday plan of action for the projects you oversee or, you can utilize machine learning technologies and perform an even deeper analysis of project delivery and benefit from the automated intelligent status calculation.
PMO as a Risk Management Resource
Absolutely all project and company management standards speak of the need for risk management. Various models, tools, and terms are available. Every PMO understands that this is important. But not everyone really means it and is ready to actually implement risk management practices in the organization. PMO, Project Managers, and Project Teams complain about the high time spent working with risks. 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.
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 action plan.
Here are examples of typical risks in project registers (generic language):
- “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.”
Sources of Risks
To deal with such risk management issues, 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), to take care of the human independence of the process, and to 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 project, to extinguish fires, and in general to hero. Such “risks” should be prevented during the preliminary planning stage of the project, preferably before signing the contract.
During the project, such unresolved problems become already sources of risk. As for the sources: typical risk sources documented in risk registers are, oddly enough, “Client,” “Team,” “environment,” etc. PMO should think about the fact that the source of a potential problem is not a generalized concept, but a specific situation. “Client,” “Team,” and “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.
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 keeping this goal in mind. It’s probably time to give an example. Is it not more useful instead of typical examples like:
- “Source”: Team.
- “Risk”: A person can get sick.
- “Impact:” will not do on time.
PMO would have the following information to work with:
- “Source”: A person (A) performing tasks on a critical path has a pregnant wife who must give birth during the period that person (A) performs her tasks (this is a fact).
- “Risk”: the above fact may result in the absence of a person (A) for more than three working days.
- “Impact:” 20% deviation from the schedule is possible.
A 20% deviation from the schedule may be a trifle for one project (where 20% is 4 working hours and the time difference with the client is 8 hours in our favor), but a real tragedy for another project (where 20% is 2 days, and the client is assigned presentation with important stakeholders for a predetermined number). Given all such 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, we need to think about its probability (Probability). The 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, 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 it. Problems begin when you need to think about risk response plans.
Risk Response Plans
Here are typical examples of a risk response plan:
- “Talk to the customer.”
- “Do not let key players go on vacation.”
- “Hold a meeting.”
Can we say how much risk will be reduced when applying these plans? That is, how effective are our Risk Management activities: how much will the probability decrease? How much damage will be reduced? A 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 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 a 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 may be this:
- To make it possible to carry out the task by another person: a daily rally on knowledge sharing with a second person (1 hour per day for the main character and 1 hour per day for backup).
- Response cost to risk = 10 “man-hours” per week, which will be an N% lag in terms of the schedule.
- Compare with the possible deviation, if the risk happens, we account for the probability of risk, and we go with this to the one who makes the decision. A possible result would be a reduction in the amount of work or acceptance by the client of one of the deviations.
Number of Risks
One of the interesting questions is, how many risks can there be on a project? The logical answer is as many 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 of it 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.”
- There are about 5-7 risks in the risk register; 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, and 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. O. these 5 “risks” are essential sources of risks.
- There is no risk register. Risks are not documented. In the best-case scenario, it’s discussed, assessed, and offers response actions, possibly even with an assessment of the response. In this case, the problems are as follows:
- You can forget to analyze 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 it. It is possible to record (and sometimes it is necessary) all identified risks, but to plan response actions – only for those whose influence on the project goals is significant.
At the same time, if you had ten risks this week and then last year, it will most likely be at least partially different risks: the situation has changed, new circumstances have appeared, and old ones have disappeared. But the sources of these dangers may be the same. That is, the whole point is the correct identification of risk. The 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’s another topic.