Risk management methods--project risk.

Kremljak, Z.

1. Introduction

Risk management represents traditionally analytical approach which was established in the framework of project management. Risk means uncertainty with known distribution of probability. In accordance with this risk analysis it represents a study which defines the outcomes of decisions together with their probabilities. In system analysis a person who makes decisions is usually worried about possibility that a project will not be implemented in a certain time period and with funds at disposal. Risk must not be confused with uncertainty and risk management does not deal with problems of structural uncertainty. of course, dealing with risk usually includes parametric uncertainty because probability distribution is not something objective but a subjective construct of planners. Real options theory and risk management must not be dealt with as two opposing approaches. Real options theory represents strategic framework for designing investment projects in the uncertain environment and for evolutionary capability development process. Project management, together with risk management represents the implementation structure which enables effective implementation of individual investment projects or project programmes whose result is the increase of knowledge in an organisational system.

Risk is a possibility that a certain problem will arise in the future. Risk does not mean the actual existence of a problem. Due to complexity and our inability to manage all details, there is always a possibility that something unexpected might happen. Risk is a fact that follows every activity and does not cause damage in itself. The damage arises only when the risk is executed. The biggest cost is usually connected to repairing the resulting damage. Assessing risk is usually about looking for errors. It is about searching for possibilities and ways of improving the state where the most widely used method is transfer of risk by ensuring suitable options.

2. Elements of risk management

Successful organisational systems strive to be excellent risk managers not only to understand risk that they deal with, but to be familiar with the way to manage it. Those organisational systems which are not successful with risk management do not provide enough time for examining the field of risk but rather leave their future in the hands of destiny (Frei & Harker, 1999).

Risk is a potential for negative future reality which can happen or not. Risk is defined by two characteristics of possible negative future event: probability of the event (will something happen) and consequences of the event (how catastrophic, if the event should occur). If the probability of the event is not known then this is uncertainty and the risk is not definable (Holmes, 2002).

Risk is not a problem. It is the perception of the level of danger according to the possible troubles. The problem is the consequence of what has already happened. Risk management is an active process which demands dedication and focus. But many cases lack data that will enable a more precise definition of the risk. As a consequence, risk management includes a high level of consideration and demands from an organisational system certain conclusion regarding the future. For example, it is quite easy to assess the probability of a car accident while the risk assessment for nuclear accident is fairly difficult. This is so because in the case of a car accident there is a lot of information available on the basis of which risk can be assessed; in the case of nuclear accident there is only little data available. This separates risk (that can be managed) from uncertainty (which in general cannot be managed). To perform risk management effectively the types of risk, to which organisations are exposed to, must be categorised and then managed accordingly (Kremljak, 2004).

Risk management is an organized method for identifying and measuring risk and for selecting, developing and implementing options for the handling of risk. It is a process, not a series of events. Risk management depends on risk management planning, early identification and analysis of risks, continuous risk tracking and reassessment, early implementation of corrective actions, communication, documentation and coordination. Though there are many ways to structure risk management, this book will structure it as having four parts: planning, assessment, handling and monitoring.

As depicted in Fig. 1 all of the parts are interlocked to demonstrate that after initial planning the parts begin to be dependent on each other. Illustrating this, Fig. 2 shows the key control and feedback relationships in the process (Kremljak, 2004).

[FIGURE 1 OMITTED]

Risk management is increasingly recognised as being concerned with both positive and negative aspects of risk. In the safety field, it is generally recognised that consequences are only negative and therefore the management of safety risk is focused on prevention and mitigation of harm (Laviolette & Seaman, 1994).

Although each risk management strategy depends upon the nature of the system being developed, research reveals that good strategies contain the same basic processes and structure shown in Fig. 3. This structure is sometimes also referred to as the risk management process model. The application of these processes varies with acquisition phases and the degree of system definition; all should be integrated into the program management function. Processes and elements of risk management include: risk, risk events, risk planning, risk assessment, risk handling, risk monitoring and risk documentation (Buchmeister et al., 2004).

[FIGURE 2 OMITTED]

[FIGURE 3 OMITTED]

2.1 Risk planning

Risk planning is the continuing process of developing an organized, comprehensive approach to risk management. The initial planning includes establishing a strategy; establishing goals and objectives; planning assessment, handling and monitoring activities; identifying resources, tasks and responsibilities; organizing and training risk management members; establishing a method to track risk items; and establishing a method to document and disseminate information on a continuous basis.

Planning begins by developing and documenting a risk management strategy. Early efforts establish the purpose and objective, assign responsibilities for specific areas, identify additional technical expertise needed, describe the assessment process and areas to consider, delineate procedures for consideration of handling options, define a risk rating scheme, dictate the reporting and documentation needs and establish report requirements and monitoring metrics.

Risk planning is the detailed formulation of a program of action for the management of risk. It is the process to:

* develop and document an organized, comprehensive and interactive risk management strategy,

* determine the methods to be used to execute a program manager's risk management strategy,

* plan for adequate resources.

Risk planning is iterative and includes describing and scheduling the activities and process to assess (identify and analyze), handle, monitor and document the risk associated with a program. The result is the risk management plan (RMP).

2.2 Risk assessment

There are many different methods used in risk management (Grey, 1995). One common method is through the use of a matrix such as shown in Fig. 4. Each item is associated with a block in the matrix to establish relative risk among them. on such a graph risk increases on the diagonal and provides a method for assessing relative risk. once the relative risk is known, a priority list can be established and risk analysis can begin.

[FIGURE 4 OMITTED]

Risk identification efforts can also include activities that help define the probability or consequences of a risk item, such as:

* testing and analyzing uncertainty away,

* testing to understand probability and consequences and

* activities that quantify risk where the qualitative nature of high, moderate, low estimates are insufficient for adequate understanding.

Fig. 5 presents how the initial identification process starts with an identification of potential risk items in each of the four risk areas. Risks related to the system performance and supporting products are generally organized by WBS and initially determined by expert assessment of teams and individuals in the development enterprise. These risks tend to be those that require follow-up quantitative assessment. Internal process and external influence risks are also determined by expert assessment within the enterprise, as well as through the use of risk area templates. These templates should be tailored for specific program use based on expert feedback.

[FIGURE 5 OMITTED]

Frequently, it happens that we are not aware of the risk. If the reason behind that is insignificance of the risk, this is not concerning. It is different, however, in case when we are not aware of a critical risk, because critical risks need to be considered, their factors have to be established, their development controlled and, if necessary, measures have to be taken in order to prevent them to become real. How important is the risk and with what seriousness it needs to be treated is shown by the critical state of the risk (quantitative approach to the risk analysis). The critical state of the risk (E) depends on the probability (P) and noxiousness (L). We express it as a product of the probability and noxiousness: E = P x L. A trouble with this risk analysis relates to unreliable and inaccurate data. The probability can seldom be exact. The qualitative approach to the risk analysis is used most frequently. The probability data is not necessary, we use only potential damage.

In this chapter, there is used a new, original quantitative manner of the risk evaluation through integral assessment of the uncertainty, which by its approach and its calculation distinguishes.

2.3 Risk handling

Risk handling includes specific methods and techniques to deal with known risks and a schedule for accomplishing tasks, identifies who is responsible for the risk area and provides an estimate of the cost and schedule associated with handling the risk, if any. It involves planning and execution with the objective of handling risks at acceptable levels. The integrated product teams (IPTs) that assess risk should begin the process to identify and evaluate handling approaches to propose to the top management, who selects the appropriate ones for implementation.

A critical part planning involves refining and selecting of the most appropriate handling options. The IPTs that evaluate the handling options may use the following criteria as a starting point for assessment:

* Can the option be feasibly implemented and still meet the user's needs?

* What is the expected effectiveness of the handling option in reducing program risk to an acceptable level?

* Is the option affordable in terms of dollars and other resources (e.g., use of critical materials, test facilities, etc.)?

* Is time available to develop and implement the option and what effect does that have on the overall program schedule?

* What effect does the option have on the system's technical performance?

* Once the risks have been categorized and analyzed, the process of handling those risks is initiated. The prime purpose of risk handling activities is to mitigate risk. Methods for doing this are numerous, but all fall into four basic categories:

* risk avoidance,

* risk control,

* risk assumption,

* risk transfer.

2.3.1 Avoidance

To avoid risk, remove requirements that represent uncertainty and high risk (probability or consequence). Avoidance includes trading off risk for performance or other capability and it is a key activity during requirements analysis. Avoidance requires understanding of priorities in requirements and constraints.

Risk avoidance involves a change in the concept, requirements, specifications and/or practices that reduce risk to an acceptable level. Simply stated it eliminates the sources of high or possibly medium risk and replaces them with a lower risk solution and may be supported by a cost/benefit analysis. Generally, this method may be done in parallel with the up-front requirements analysis, supported by cost / requirement trade studies.

2.3.2 Control

Control is the deliberate use of the design process to lower the risk to acceptable levels. It requires the disciplined application of the systems engineering process and detailed knowledge of the technical area associated with the design. control techniques are plentiful and include:

* multiple concurrent design to provide more than one design path to a solution,

* alternative low-risk design to minimize the risk of a design solution by using the lowest-risk design option,

* incremental development, such as pre-planned product improvement,

* to dissociate the design from high-risk components that can be developed separately,

* technology maturation that allows high-risk components to be developed separately while the basic development uses a less risky and lower-performance temporary substitute,

* test, analyze and fix that allows understanding to lead to lower risk design changes (test can be replaced by demonstration,

* inspection, early prototyping, reviews, metric tracking,

* experimentation, models and mock-ups, simulation or any other input or set of inputs that gives a better understanding of the risk),

* robust design that produces a design with substantial margin such that risk is reduced,

* the open system approach that emphasizes use of generally accepted interface standards that provide proven solutions to component design problems.

2.3.3 Assumption

Risk assumption is an acknowledgment of the existence of a particular risk situation and a conscious decision to accept the associated level of risk, without engaging in any special efforts to control it. However, a general cost and schedule reserve may be set aside to deal with any problems that may occur as a result of various risk assumption decisions. This method recognizes that not all identified program risks warrant special handling; as such, it is most suited for those situations that have been classified as low risk. The key to successful risk assumption is twofold:

* Identify the resources (time, money, people, etc.) needed to overcome a risk if it materializes. This includes identifying the specific management actions (such as retesting, additional time for further design activities) that may occur.

* Ensure that necessary administrative actions are taken to identify a management reserve to accomplish those management actions.

Risk-handling options have broad cost implications. The magnitude of these costs is circumstance-dependent. The approval and funding of handling options should be part of the process that establishes the program cost and performance goals. This should normally be done by the program-level risk management IPT or risk management board. The selected handling option should be included in the program's acquisition strategy.

2.3.4 Transfer

Transfer can be used to reduce risk by moving the risk from one area of design to another where a design solution is less risky. Examples of this include:

* assignment to hardware (versus software) or vice versa,

* use of functional partitioning to allocate performance based on risk factors.

Transfer is most associated with the act of assigning, delegating or paying someone to assume the risk. To some extent transfer always occurs when contracting or tasking another activity. Typical methods include insurance, warranties and incentive clauses. Risk is never truly transferred. If the risk is not mitigated by the delegated activity it still affects your project or program.

Key areas to review before using transfer are:

* How well can the delegated activity handle the risk? Transfer is effective only to the level the risk taker can handle it.

* How well will the delegated activity solution integrate into your project or program? Transfer is effective only if the method is integrated with the overall effort. For example, is the warranty action coordinated with operators and maintainers?

* Was the method of tasking the delegated activity proper? Transfer is effective only if the transfer mechanism is valid. For example, can incentives be "gamed"?

2.4 Risk monitoring

Risk monitoring and control is the process of keeping track of the identified risks, monitoring residual risks and identifying new risks, ensuring the execution of risk plans and evaluating their effectiveness in reducing risk. Risk monitoring and control records risk metrics that are associated with implementing contingency plans. Risk monitoring and control is an ongoing process for the life of the project. The risks change as the project matures, new risks develop or anticipated risks disappear.

Good risk monitoring and control processes provide information that assists with making effective decisions in advance of the risk's occurring. Communication to all project stakeholders is needed to assess periodically the acceptability of the level of risk on the project (***--PRM, 2010).

3. Qualitative analysis of project risk

Project risk is an uncertain event or condition that, if it occurs, has a positive or a negative effect on a project objective. A risk has a cause and, if it occurs, a consequence. The risk event is that the permit may take longer than planned or the personnel may not be adequate for the task. If either of these uncertain events occur, there will be a consequence on the project cost, schedule or quality. Risk conditions could include aspects of the project environment that may contribute to project risk such as poor project management practices or dependency on external participants that cannot be controlled (Augier, & Kreiner, 2000).

Fig. 6 provides an overview of the following major processes: Risk management planning, Risk identification, Qualitative risk analysis, Quantitative risk analysis, Risk response planning, Risk monitoring and control.

In projects whose results are not only tangible resources but also capabilities, qualitative risk assessment is important. Qualitative risk analysis is a process of evaluating influence and certainty of recognized risks. Risks are arranged according to their potential influence on project goals.

[FIGURE 6 OMITTED]

Qualitative risk analysis is one of the ways to define importance of treatment of individual risks and managing reaction to risk. Time aspect can rather increase the importance of risk. Assessing the quality of available information can also help manage the assessment. For qualitative risk analysis one must assess the probability and consequences of risk with established methods and tools for qualitative analysis.

3.1 Interviews with experts

A difficult part of the risk management process is data gathering. This technique provides a means for collecting risk-related data from subject-matter experts and from people who are intimately involved with the various aspects of the program. It relies on "expert" judgment to identify and analyze risk events, develop alternatives and provide "analyzed" data. It is used almost exclusively in a support role to help develop technical data, such as probability and consequences/impacts information, required by a primary risk assessment technique. It can address all the functional areas that make up the critical risk areas and processes and can be used in support of risk handling. Expert judgment is a sound and practical way of obtaining necessary information that is not available elsewhere or practical to develop using engineering or scientific techniques. However, interviewers should be aware that expert opinions may be biased because of over-reliance on certain information and neglect of other information; unwarranted confidence; the tendency to recall most frequent and most recent events; a tendency to neglect rare events; and motivation. Results may have to be tempered because of these biases.

3.2 Analogy comparison/lessons-learned studies

This technique uses lessons learned and historical information about the risk associated with programs that are similar to the new system to identify the risk associated with a new program. It is normally used to support other primary risk assessment techniques, e.g., Product (WBS) Risk Assessment, Process Risk Assessment, etc. The technique is based upon the concept that "new" programs are originated or evolved from existing programs or simply represent a new combination of existing components or subsystems. This technique is most appropriate when systems engineering and systems integration issues, plus software development, are minimal. A logical extension of this premise is that key insights can be gained concerning aspects of a current program's risks by examining the successes, failures, problems and solutions of similar existing or past programs. This technique addresses all the functional areas that make up the critical risk areas and processes.

The first step in this approach is to select or develop a baseline comparison system (BCS) that closely approximates the characteristics of the new system/equipment to as low a level as possible and uses the processes similar to those that are needed to develop the new system. For processes, industry-wide best practices should be used as a baseline. Relevant BcS data are then collected, analyzed and compared with the new system requirements. The BCS data may require adjustment to make a valid comparison; for example, apply appropriate inflation indices for cost comparisons, adjust design schedule for software evolution versus software development, etc. The comparisons can be a major source of risk assessment data and provide some indication of areas that should be investigated further.

3.3 Inputs to qualitative project risk analysis

Holmes (2002) identifies the following levels of qualitative project risk analysis:

* Risk management plan;

* Identified risks--risks discovered during the risk identification process are evaluated along with their potential impacts on the project;

* Project status--the uncertainty of a risk often depends on the project's progress through its life cycle. Early in the project, many risks have not surfaced, the design for the project is immature and changes can occur, making it likely that more risks will be discovered.

* Project type--projects of a common or recurrent type tend to have better understood probability of occurrence of risk events and their consequences. Projects using state-of-the-art or first-of-its-kind technology--or highly complex projects--tend to have more uncertainty.

* Data precision--precision describes the extent to which a risk is known and understood. It measures the extent of data available, as well as the reliability of data. The source of the data that was used to identify the risk must be evaluated.

* Scales of probability and impact--these scales are to be used in assessing the two key dimensions of risk; probability and consequences.

* Assumptions--assumptions identified during the risk identification process are evaluated as potential risks.

3.4 Tools and techniques for qualitative project risk analysis

Risk probability and impact--risk probability and risk consequences may be described in qualitative terms such as very high, high, moderate, low and very low. Risk probability is the likelihood that a risk will occur. Risk consequences are the effect on project objectives if the risk event occurs. These two dimensions of risk are applied to specific risk events, not to the overall project. Analysis of risks using probability and consequences helps identify those risks that should be managed aggressively.

* Probability/impact risk rating matrix--a matrix may be constructed that assigns risk ratings (very low, low, moderate, high and very high) to risks or conditions based on combining probability and impact scales. Risks with high probability and high impact are likely to require further analysis, including quantification and aggressive risk management. The risk rating is accomplished using a matrix and risk scales for each risk.

* Project assumptions testing--identified assumptions must be tested against two criteria: assumption stability and the consequences on the project if the assumption is false. Alternative assumptions that may be true should be identified and their consequences on the project objectives tested in the qualitative risk-analysis process.

Data precision ranking--qualitative risk analysis requires accurate and unbiased data if it is to be helpful to project management. Data precision ranking is a technique to evaluate the degree to which the data about risks is useful for risk management. It involves examining extent of understanding of the risk, data available about the risk, quality of the data, reliability and integrity of the data.

3.5 Outputs from qualitative project risk analysis

Overall risk ranking for the project--risk ranking may indicate the overall risk position of a project relative to other projects by comparing the risk scores. It can be used to assign personnel or other resources to projects with different risk rankings, to make a benefit-cost analysis decision about the project or to support a recommendation cancellation.

List of prioritized risks--risks and conditions can be prioritized by a number of criteria. These include rank (high, moderate and low) or WBS level. Risks may also be grouped by those that require an immediate response and those that can be handled at a later date. Risks that affect cost, schedule, functionality and quality may be assessed separately with different ratings. Significant risks should have a description of the basis for the assessed probability and impact.

List of risks for additional analysis and management--risks classified as high or moderate would be prime candidates for more analysis, including quantitative risk analysis and for risk management action.

Risk assessment, risk management and qualitative project risk analysis also represent areas for development of projects. The results of these projects are organizational system capabilities (Kremljak & Buchmeister, 2006).

4. Conclusion

Decision making has always been a difficult task. When considered in the context of our social and economic goals and behaviours it is also a very important task. In the past we have seen a convergence of ideas and a breakdown in the barriers between different and sometimes competing disciplines. Scientists with different backgrounds are participating in multi-disciplinary developments. The main motivation is to create tools which help us to make better decisions (Mitra, 1988).

Manufacturing is and will remain one of the principal means by which wealth is created. However manufacturing has changed radically over the course of the last 20 years and rapid changes are certain to continue. The emergence of new manufacturing technologies, spurred by intense competition, will lead to dramatically new products and processes. New management and labour practices, organizational structures, and decision making methods will also emerge as complements to new products and processes. It is essential that the manufacturing industry be prepared to implement advanced manufacturing methods in time (Trigeorgis, 2002).

These changes have led organizations to search for new approaches in organization models and in production management. Uncertainty and fast changing environment are making long-term planning next to impossible. This uncertain environment is leaving only time and risk as means for survival. Decision-making has become one of the most challenging tasks in these unpredictable global conditions, demanding competency in understanding these complicated processes.

Managers employed in industrial companies, the public sector and service industry cope with high levels of uncertainty in their decision-making processes, due to rapid, large-scale changes that define the environment their companies operate in. This means that managers do not possess complete information on future events, do not know all possible alternatives or consequences of all possible decisions.

Decision-making in high-risk conditions is becoming a common area for research within strategic management, organizational theory, research and development management and industrial engineering (Boender et al., 1989). These issues have not been adequately addressed in published research.

Tackling uncertainty involves developing heuristic tools that can offer satisfactory solutions. The problem of decision-making in uncertain conditions is only partially presented in relevant literature (Carpenter & Fredrickson, 2001). Intensive research in the area of multi-level decision-making, supported by expert systems is currently under way.

DOI: 10.2507/daaam.scibook.2011.10

5. References

Augier, M. & Kreiner, K. (2000). Rationality, imagination and intelligence: some boundaries in human decision-making. Industrial and Corporate Change, Vol. 9, No. 4, 659-679

Boender, C. G. E.; de Grann, J. G. & Lootsma, F. A. (1989). Multicriteria decision analysis with fuzzy pairwise comparison. Fuzzy Sets and Systems, Vol. 29, 133-143

Buchmeister, B.; Pandza, K.; Kremljak, Z. & Polajnar, A. (2004). Possibilities of practical use of risk management, Proceedings of 3rd International scientific conference Business systems management, University of Mostar

Carpenter, M. A. & Fredrickson, J. W. (2001). Top management teams, global strategic posture, and the moderating role of uncertainty. Academy of Management Journal, Vol. 44, No. 1, 533-545

Frei, F. X. & Harker, P. T. (1999). Measuring aggregate process performance using AHP. European Journal of Operational Research, Vol. 116, 436-442

Grey, S. (1995). Practical Risk Assessment for Project Management, John Wiley & Sons, Chicester

Holmes, A. (2002). Risk management, Capstone Publishing, Oxford

Kremljak, Z. (2004). Decision making under risk, DAAAM International, Vienna

Kremljak, Z. & Buchmeister, B. (2006). Uncertainty and development of capabilities, DAAAM International Publishing, Vienna

Laviolette, M. & Seaman, J. W. (1994). The efficacy of fuzzy representations of uncertainty. IEEE Transactions on Fuzzy Systems, Vol. 2, No. 1, 4-15

Mitra, G. (1988). Mathematical models for decision support, Springer-Verlag, Berlin

Trigeorgis, L. (2002). Real options-Managerial flexibility and strategy in resource allocation, MIT Press, Cambridge

*** (2011) http://www.wsdot.wa.gov/publications/fulltext/cevp/ProjectRisk Management.pdf-Project Risk Management Guidance for WSDOT Projects (2010), Accessed on 2011-05-17

Authors' data: Assistant Prof. Dr. Sc. Kremljak, Z[vonko]; Ministry of the Economy, Kotnikova 5, SI-1000 Ljubljana, Slovenia, zvonko.kremljak@s5.net