CHAPTER 6

Risk Management

Risk management is a specialism and continuous process as projects and programs unfold (see Figure 6.1). The effectiveness of a risk management process highly depends on the ability to identify risks in the first place. So historical data on similar projects is useful to this end, together with the ability to detect threat. Risk management has been covered extensively in the literature, contributing to the wealth of knowledge. What characterizes HybridP3M’s risk management process is a simple, at a high-level linear process that takes into account the implications of countermeasures (based on causality) by addressing interdependencies and adjustments. This approach is rooted in decision making and cause and effect, or simply project behavior, as outlined by the Cases method, which captures problem + solution scenarios (Rosinski 2019). The basic assumption is that the impact of countermeasures can be anticipated based on foresight, enabling adjustments based on decision implications. And secondly, that the actual impact of countermeasures is to a degree uncertain, with unprecedented implications due to unexpected project behavior, that is, nonobvious cause and effects. Essentially, risk management involves a decision-making process driven by the need for risk mitigation.

Identify Risks

The first step is to identify risks. Risks capture all things that can go wrong or not as expected. It takes a creative mind and (negative) experience to identify such phenomena. Every risk identified as one is usually a summary of a risk, captured in one line, for the purpose of brevity, which needs to be elaborated and explained. So the contextual information of risk is important as well. While the roots of risk are unlimited, it may be possible to categorize risk, for example, based on taxonomies. Such categorization can arguably make the search for risks easier. A common divide is risks common to the business/industry in general and risks specific to an organization, for example, rooted in certain product characteristics—either penetrating an existing market or new market development, depending on differentiation. Examples of risks in case of new online venture, combined with new product development, a complex change initiative, include entry of new competitors, online user growth does not meet expectations, no loan from the bank, bullying by copyright/ trademark owners, low conversion to premium (paid) accounts, launch of substitutes, and so on. One example of an existing taxonomy is the one that follows the RISMAN method, in which there are seven perspectives relevant to risk: (1) political/governance, (2) financial/economical, (3) legal, (4) technical, (5) organizational, (6) geographical, and (7) societal.

Figure 6.1 Risk management PDD

Analyze Risk Impact and Risk Probability

The second step is to analyze risk impact and risk probability, using easy to use scales. Risk impact refers to the consequences of risk once it materializes (the actual damage), whereas risk probability refers to the likelihood a risk materializes. This type of analysis makes it possible to prioritize focus. It provides the risk manager a tool to prioritize related countermeasures, identified at a later stage, as well. Performing step 2, following step 1, will result in a standardized table. In this table, every identified risk gets an ID and assessment of risk impact and risk probability. The most common scale is low–medium–high. Obviously, if impact or probability is high, or a combination, then the associated risks should receive great attention.

Set Risk Tolerances

Risk tolerance is the degree of how much of a risk one is willing to take. More specifically, for each specific risk, partly defined by risk impact and risk probability, risk tolerance is the degree of accepting risk without planning and implementing countermeasures. Accepting risk is effectively a function of risk impact and risk probability, and thus, it relates to risk impact and risk probability. So if these two variables change based on new insight thanks to dynamic risk analysis and risk tolerance does not, then either countermeasures are required or a new level of risk tolerance. From a proactive stance, risk tolerance also depends on potential countermeasures. If risk can be mitigated by potential countermeasures effectively, this will justify risk tolerance. In other words, if things go wrong, the negative impact can be minimized. This point of view provides a new meaning to risk tolerance as a function of countermeasure effectiveness, in addition to risk impact and risk probability. The latter extended meaning of risk tolerance relies on identification of potential countermeasures, which is the next step anyway.

Define Potential Countermeasures

For every identified risk, HybridP3M recommends to define one or more potential countermeasures. Such countermeasures either limit risk impact or risk probability, or a combination. In other words, countermeasures either mitigate negative effects in case risk materializes or prevent risk from materializing in the first place. Every defined potential countermeasure should be feasible in alignment with the current situation. Also, every countermeasure has innate advantages and disadvantages, depending on the countermeasure impact, which are worth recording.

Select and Implement Countermeasures

Not every identified potential countermeasure needs to be implemented. This depends on factors such as risk priority and countermeasure effectiveness. So there is a step that involves the selection of countermeasures ready for implementation. While risk management is a specialism performed by the risk manager, decision making affecting the project or program as a whole—with serious consequences/impact—involves project manager authority or even project board authority. So this step is a joint responsibility of the risk manager and project manager, who may escalate an issue to the project board in the spirit of the decision-making process, especially when project tolerances are under threat. After selection of countermeasures ready to be implemented—following decision making—the implementation process starts. Implementation requires project manager authority and involves change to the project management environment, project management processes, or delivery processes. So every selected countermeasure may benefit from change management, essentially a leadership process delegated over project management roles, not a separate project management function according to HybridP3M. Note that a change manager role is a specialist role dealing with project outcomes, especially in case of change initiatives.

Map Interdependencies and Make Adjustments

The implementation of selected countermeasures should trigger analysis of interdependencies, either prior to implementation or in the act itself, setting project behavior in motion. The project management environment subject to various internal and external, management, and specialist processes could be regarded as a complex system. Changes to this system based on corrective measures related to risk management undoubtedly influence project behavior, either in a negative, positive, or neutral way (but often with managerial implications). The key is to control project behavior in such a way that it does not conflict with desired project outcomes, including project results, nor jeopardize project success as viewed by project stakeholders. Therefore, it is essential to map interdependencies of implemented countermeasures in order to better understand the system as a whole for the benefit of prediction and management control. A best practice in this type of analysis is to analyze the measure’s impact on every single project/program and P3M function. Recall that HybridP3M’s processes are directly derived from functions. Accordingly, it is recommended to develop additional tools such as checklists to see how countermeasures affect the relevant functions. Following a mapping of selected countermeasures and interdependencies, adjustments need to be made. These adjustments relate to the aforementioned functions, such as project planning, various assumptions at the foundation of the project or program (e.g., tolerances, business case, and market knowledge), and the project management environment in general. Making these adjustments will likely affect project management processes and requires alignment with other persons taking responsibility for process and role. For example, if a specific countermeasure implies purposeful delay, affecting project planning, the project planner may require a new planning tolerance in order to prevent an exception, and thus, more project board intervention.

Analyze Impact of Countermeasure

Every implemented countermeasure follows a decision-making process leading to action. Taken decision and actions combined correspond to a human response to a problem. Risk management problems, called risks, pose an initial problem that might be dealt with countermeasures on the outset. Hence, risk management can be approached by a decision making and project behavior inducing paradigm, the foundation behind the Cases method (Rosinski 2019). What can be learned from this specific paradigm is that there are feedback loops inherent to management events. There is a distinction between what is expected and what actually happens, the outcome of decision making. So in order to solve the initial problem, additional actions may be required. Or the initial problem evolves into different problem or set of problems, calling for alternative action. Therefore, in practice, risk management may lead to unexpected project behavior. Accordingly, it is the task of the risk manager to analyze the impact of countermeasures over a course of time. This will enable understanding of the new situation, the effectiveness of taken countermeasures, and may lead to better decision making in the next iteration of the problem (risk) situation. The next iteration(s) of solving the risk calls for the next step: “Make additional adjustments.”

Make Additional Adjustments

Based on risk status, as it evolves over time, one may conclude impact of countermeasures and thereby acknowledge the end of iteration. Every iteration is characterized by project behavior in terms of actual outcome, as the result of taken decision and actions, in this case, risk countermeasures. Actual outcome may reflect changes to risk impact, risk probability, or simply risk resolution in which risk is no longer actual. The actual outcome may trigger additional countermeasures, which are additional adjustments. The process is potentially iterative, depending on risk complexity, selecting a particular countermeasure and emergent factors. These factors all contribute to unexpected project behavior, and thus, unanticipated actual outcomes. The advantage of this iterative approach to risk management is that in most cases it will lead to successful resolution of risk thanks to implementation of effective countermeasures. If risk cannot be resolved and at the same time cannot be tolerated, the situation may result in a premature end of the project or program, as decided by project board members. In order to capture risk management knowledge for future reference, it is recommended to apply the Cases method introduced by Rosinski (2019). The Cases method is a decision-making tool for problems and can be used for risk.

Prematurely End the Project or Program

If the original risk countermeasure or follow-up countermeasures (in case of iterative problem solving) are effective, either resolve the risk or lead to intelligent risk tolerance, then one can speak of successful risk management. The opposite case of unresolved risk can lead to a premature end of the project or program, depending on risk tolerance. Risk tolerance is established by the project board and affects the business case. If risk is not tolerable, the project board may conclude that the project or program is not worthwhile. So risk partly determines viability. Arguably, many projects or programs fail because they lack a sound risk management process. Such process helps to resolve risk, or in case that is no longer an option, it provides a safeguard against sunk costs (when simply ending the project or program is the best option). That is to say, such projects and programs carry on based on the wrong premises, rooted in a faulty business case.

Process Aspects

Figure 6.2 captures the knowledge nature of risk management.

Figure 6.2 Tacit–explicit continuum of risk management

While risk capture results in explicit risk, risk management also involves tacit knowledge. Risk mitigation based on countermeasures is a problem-solving paradigm which depends on tacit knowledge of countermeasure effectiveness. Also risk analysis in terms of risk impact and risk probability has tacit dimensions. Overall, risk management contributes to explicit knowledge on risk and its management.

Figure 6.3 captures the manageability of risk management.

Figure 6.3 Step-by-step process versus skilled activity continuum of risk management

The process of mitigating risks is a manageable process consisting of clear, nonambiguous steps. Risk management can be effectively promoted based on corporate standards. Although it is a specialization rooted in a unique knowledge domain, it is not a specialization that requires difficult to copy skills, relatively speaking. In other words, the systematic approach behind risk management is relatively easy to grasp, except the essence of decision making relevant in this context.

Figure 6.4 captures the specialization level of risk management.

Figure 6.4 Management–specialist continuum of risk management

As mentioned earlier, risk management is a specialization. Depending on the project or program, the distinct risk manager role is combined with the project manager role (or there is no awareness of a separate role). Generally, project managers should understand risk management and acknowledge its importance. So the mentioned combination is not something far-fetched. In fact, although propagated by HybridP3M, a separate risk manager role is not common practice across industries in the present state.

Figure 6.5 captures IT support in relation to risk management.

Figure 6.5 Available IT support for risk management

Maybe surprisingly the market offers a significant number of risk management tools. Surprisingly because risk management can be performed using simple Excel sheets at most. Clearly, available software builds upon the analytical dimension of risk. The tools in the market effectively combine risk data and display information in the style of either reports or some kind of dashboards. Generally, the goal of these tools is to support monitoring of risk. Also, some tools enable intelligent aggregation of risk data.

Figure 6.6 captures the complexity of risk management.

Figure 6.6 Task complexity scale of risk management

As a process, risk management is rather straightforward. But the decision-making dimension makes it more complex. Risk has a big impact on projects and programs, so risk mitigation calls for deliberation and sound decision making.

MAIDEO Requirements

Table 6.1 presents MAIDEO requirements related to “risk management.”

Table 6.1 MAIDEO requirements related to risk management