When planning a project to meet targets for cost, schedule, or quality, it is useful to identify likely risks to the success of the project. A risk is any possible situation that is not planned for, but that, if it occurs, is likely to divert the project from its planned result. For example, an established project team plans for the work to be done by its staff, but there is the risk that an employee may unexpectedly leave the team.
In Project Management, the Risk Management Process has the objectives of identifying, assessing, and managing risks, both positive and negative. All too often, project managers focus only on negative risk, however, good things can happen in a project, "things" that were foreseen, but not expressly planned.
The objective of Risk Management is to predict risks, assess their likelihood and impact, and to actively plan what should be done ahead of time to best deal with situations when they occur.
The risk management process usually occurs in five distinct steps: plan risk management, risk identification, qualitative and quantitative risk analysis, risk response planning, and risk monitoring and control. The central point of risk identification and assessment in risk management is understanding the risk. However, this is also where project managers and risk subject-matter experts (SMEs) get the least help from recognized references, best practices, or work standards.
Currently, the Project Management Institute (PMIr) has a team of SMEs working on a Practice Standard for Risk Management. This team has identified one very good tool: the Risk Breakdown Structure (RBS). The RBS helps the project manager, the risk manager, and almost any stakeholder to understand, and therefore be able to identify and assess risk.
What is a "Risk Breakdown Structure?"
The RBS will prove extremely valuable to better grasp when a project needs to receive special scrutiny, in other words, when risk might happen. The RBS can also help the project manager and the risk manager to better understand recurring risks and concentrations of risk that could lead to issues that affect the status of the project.
Following the concept of the Work Breakdown Structure (WBS), the Risk Breakdown Structure provides a means for the project manager and risk manager to structure the risks being addressed or tracked. Just as PMI defines the Work Breakdown Structure as a "deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project..." the RBS could be considered as a "hierarchically organized depiction of the identified project risks arranged by risk category."
In project management language, risks include anything unplanned and unforeseen that can have a negative impact on the project's costs, timing or quality. [This does not conform to the ISO 31000 view of Risk] A good project manager should be able to manage the risks effectively and get the project on track.
Many project managers and risk managers currently use "home-grown" methods for listing, identifying, assessing, and tracking risks in their projects. These methods include: spreadsheets, listing, generic risk taxonomy, based somewhat loosely on various standards and guidelines. [3][4][5]
An approach that simply places the risks in a list, a simple table, or even in a database does not provide the strength of using a structured, organized method similar to a Work Breakdown Structure. To fully understand the risks and better identify and assess the risk, a "deep-dive" into each risk, recording as many levels of identification as necessary, may be required. The project value of placing risks in a structure such as this lies in the ability of the project manager and risk manager to then quickly and easily identify and assess the risk, identify the potential risk triggers, and develop a more robust risk response plan .[6] If all risks are placed in a hierarchical structure as they are identified, and the structure is organized by source, the total risk exposure to the project can be more easily understood, and planning for the risk more easily accomplished.
The concept of the RBS is new. The PMBoK (2004), barely references its use; however, the PMI Standards team has incorporated the RBS in the Practice Standard for Risk Management (draft for release in 2009). The PMBoK provides an example graphic of the RBS in Chapter 11, Figure 11.4. This reference has as major topics: Technical, External, Organizational, and Project Management. Another source [7] provides the following major topics: Technical, Management, Organizational, External, and Project Management. Dr. David Hillson, in the proceedings of the Project Management Institute Annual Seminars and Symposium, on Oct. 3–10, 2002,[8] provided several different RBS Structure examples, with topics similar to those already shown. Dr. Hillson broke out two different examples, an RBS for Software Development, which had the following major topics: Product Engineering, Development Environment, Program Constraints; and an RBS for Construction Design, which has these major topics: Environment, Industry, Client, Project.
Each RBS is broken into "levels", with each level providing a more in-depth "view" of the identified risk. As an example, in creating a RBS for software development, Level 1 of the RBS might be Technical, followed by Level 2, Requirements, followed by Level 3, Functional Requirements, Informational Requirements, Non-functional Requirements, etc. If desired, Level 3 can be further refined with Level 4, Stability, Completeness, Functionality, Interfaces, Testability, etc., Level 5, etc.
Once the project team has created its RBS, then individual risks can be identified. Several different techniques for defining the individual risks are available, including brain-storming, surveys, workshops, etc. Each identified risk needs to be categorized, and placed in the RBS under a specific topic (or topics) if the risk spans two or more topics, such as a risk in gathering requirements might span Technical, organizational and project management.
NOTE: the RBS will be different between projects, even projects within the same project area, e.g., construction, information technology, environmental remediation, etc.
After the RBS has completed its first "pass" in the creation phase, it can then become an input to qualitative risk analysis, where probabilities, priorities, and impacts are determined.
Creation of tailor-made Risk Breakdown Structures
An example of designed tailor-made Risk Breakdown Structure, with results of a multi-objective risk analysis
Construction projects, like all complex activities, involve many partners with different objectives, who are subjected to many risks in an uncertain environment. In practice, different project stakeholders have different understanding and perception of project risks. Each one identifies and analyzes the project risks regarding his objectives, risk attitude and special perspective to project risks without relying on a common and shared methodology. This is why in most of construction projects, discussing the project risks and making risk based decisions are of common difficulties which may also cause to disputes between project parties. Also, the project risk management is a scalable activity and should be commensurate with the size, level of available information and complexity of the project under consideration. Furthermore, this process is iterative, since in each phase of the project, new information is available and some predicted risks events occur while others will not, new unpredicted risk events may occur or may be identified, and the characteristics of those already identified may change. Thus, an iterative risk management should be carried out at all stages of the project life cycle. As consequence, the project risk management process has to be tailored for each particular case and project.
Dr. Rasool Mehdizadeh has developed a methodology for a dynamic, multi-scale and multi-perspective risk management of construction projects.[9] This method is based on the application of tailor-made risk breakdown structures (RBS) which are well adapted to: (1) the stage and degree of development of project, (2) specific requirements and objectives of project stakeholders, and (3) required level of details. Using this method, each of the project stakeholders, at each stage of the project, considering his/her special view to project risks, can build his/her own specific RBS. Moreover, the RBS can also be tailored as a shared support for all the project stakeholders in order to facilitate understanding and discussing project risks. Using these tailored RBSs which are all generated using a unique procedure and knowledge database, each of project stakeholders can identify, analyze and represent the project risks regarding his/her point of view and requirements. The method ensures the consistency of all these perspectives.
Using the hierarchical Risk Breakdown Structure
The RBS serves as more than just a "database" for identifying risks to the project. When created, the RBS provides a vehicle for risk analysis and reporting, and risk comparison across projects. Most importantly, the RBS is "the" tool for risk identification.[10][11]
Risk Identification and classification
Risk identification will be the first step in determining which risks may affect a project. Identification also provides documentation of the risk characteristics. The first level (Level 1) of the RBS can be used as a sanity check to make certain that all topics that might include risk are covered during the risk identification process. Using the RBS, an iterative process can be initiated that will persist throughout the project life-cycle. The frequency and applicability of this iterative process will be different in each phase of the life-cycle[12]
Using a risk identification checklist that is focused on the RBS, using Levels 2, 3 and below, assists in identifying specific and generic risks. This checklist can then become a part of the project managers' and risk managers' tool set for future projects.
Risk identification leads to quantitative risk analysis, conducted by the Project Risk Manager. Sometimes merely identifying the risk will suggest the proper response, which can be entered into the Risk Response Plan.
Risk Analysis
Qualitative Risk Analysis
Risk analysis is more easily achieved if, after identification, the risks are placed in proper perspective within the RBS by categorizing the risks in the various levels. Risk analysis involves the use of techniques for prioritizing the risk, determining the probability of the risk, and calculating the impact of the risk. At no point should the project manager or risk manager decide that the total number of identified risks should cause the cancellation of the project. The total number does not take into account the probability with which the risk will occur, nor the impact to the project, should the risk occur. A few risks, with high probabilities and high impact, are far more critical to the overall success of the project than a large number of risks with low probability and minimal impact. Using the RBS, the project manager and the risk manager should create a "risk score" based on the priority, probability and impact of each risk, and with each "group" of risks (according to the appropriate Level of the RBS).
Using the RBS also offers other valuable understanding into the analysis of the identified risks. Some of these new understandings are:
Another benefit of the RBS is the ability to focus risk responses to the high probability, high impact, high priority risks using the risk topic groupings.[14]
A specific method was developed by Dr. Mehdizadeh in order to: (1) calculate risk values of risk events regarding different project objectives, (2) aggregate the risk values through the RBS branches and also (3) to calculate global risk score of project.[9] The method combines consistently the quantitative and qualitative approaches, allowing the user to choose the best one for risk assessment at any level, based on the available information and required accuracy. In this method, at the first step, the probability and impact factors of risk events are assessed quantitatively or qualitatively. Two concomitant scales are used: a continuous cardinal scale and a discrete ordinal scale ranging from 1 to 5. Each scale has its own advantage. Continuous scale is closer to physical reality and has a more concrete meaning while discrete scale has a strong symbolic value. The assessments based on each of these scales can be converted to the other one following a defined process. At the second step, the risk values of risk events are calculated and then aggregated through the RBS branches in order to calculate the risk values of risk categories. Finally, application of a multi-criteria decision method allows calculating the global risk score of each category. This method provides a more consistent approach to get more realistic results without suffering from the usual weaknesses of available methods cited in literature.
Summary
Effective risk management demands that the project manager and risk manager fully understand the risks of a project. A successful risk management process would also require a good knowledge and understanding of the business objectives of the project. During risk identification, a large volume of risks can be identified. Simply listing these risks or putting them in a spreadsheet or database does not provide the in-depth understanding of the identified risks necessary to allow a solid risk response planning task. The RBS provides the tool necessary to assist in identifying risks, analyzing risks, and creating a successful risk response plan, and it provides a vehicle for "deep-dives" into the complexity of the risk. Using a hierarchical RBS, similar in its design to the WBS, allows the project and risk managers the opportunity to carefully align the risks in proper categories, using as deep an analysis as time and resources would permit.[15]
Project management is the process of leading the work of a team to achieve all project goals within the given constraints. This information is usually described in project documentation, created at the beginning of the development process. The primary constraints are scope, time, and budget. The secondary challenge is to optimize the allocation of necessary inputs and apply them to meet pre-defined objectives.
Risk management is the identification, evaluation, and prioritization of risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events or to maximize the realization of opportunities.
A project plan, according to the Project Management Body of Knowledge (PMBOK), is: "...a formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among project stakeholders, and document approved scope, cost, and schedule baselines. A project plan may be summarized or detailed."
Critical chain project management (CCPM) is a method of planning and managing projects that emphasizes the resources required to execute project tasks. It was developed by Eliyahu M. Goldratt. It differs from more traditional methods that derive from critical path and PERT algorithms, which emphasize task order and rigid scheduling. A critical chain project network strives to keep resources levelled, and requires that they be flexible in start times.
The Project Management Body of Knowledge (PMBOK) is a set of standard terminology and guidelines for project management. The body of knowledge evolves over time and is presented in A Guide to the Project Management Body of Knowledge, a book whose seventh edition was released in 2021. This document results from work overseen by the Project Management Institute (PMI), which offers the CAPM and PMP certifications.
Risk assessment determines possible mishaps, their likelihood and consequences, and the tolerances for such events. The results of this process may be expressed in a quantitative or qualitative fashion. Risk assessment is an inherent part of a broader risk management strategy to help reduce any potential risk-related consequences.
Failure mode and effects analysis is the process of reviewing as many components, assemblies, and subsystems as possible to identify potential failure modes in a system and their causes and effects. For each component, the failure modes and their resulting effects on the rest of the system are recorded in a specific FMEA worksheet. There are numerous variations of such worksheets. An FMEA can be a qualitative analysis, but may be put on a quantitative basis when mathematical failure rate models are combined with a statistical failure mode ratio database. It was one of the first highly structured, systematic techniques for failure analysis. It was developed by reliability engineers in the late 1950s to study problems that might arise from malfunctions of military systems. An FMEA is often the first step of a system reliability study.
The Information Services Procurement Library (ISPL) is a best practice library for the management of Information Technology related acquisition processes. It helps both the customer and supplier organization to achieve the desired quality using the corresponded amount of time and money by providing methods and best practices for risk management, contract management, and planning. ISPL focuses on the relationship between the customer and supplier organization: It helps constructing the request for proposal, it helps constructing the contract and delivery plan according to the project situation and risks, and it helps monitoring the delivery phase. ISPL is a unique Information Technology method because where most other Information Technology methods and frameworks focus on development, ISPL focuses purely on the procurement of information services. The target audience for ISPL consists of procurement managers, acquisition managers, programme managers, contract managers, facilities managers, service level managers, and project managers in the IT area. Because of ISPL's focus on procurement it is very suitable to be used with ITIL and PRINCE2.
Business analysis is a professional discipline focussed on identifying business needs and determining solutions to business problems. Solutions may include a software-systems development component, process improvements, or organizational changes, and may involve extensive analysis, strategic planning and policy development. A person dedicated to carrying out these tasks within an organization is called a business analyst or BA.
Software project management is the process of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.
Stakeholder analysis is the process of assessing a system and potential changes to it as they relate to relevant and interested parties (stakeholders). This information is used to assess how the interests of those stakeholders should be addressed in a project plan, policy, program, or other action. Stakeholder analysis is a key part of stakeholder management. A stakeholder analysis of an issue consists of weighing and balancing all of the competing demands on a firm by each of those who have a claim on it, in order to arrive at the firm's obligation in a particular case. A stakeholder analysis does not preclude the interests of the stakeholders overriding the interests of the other stakeholders affected, but it ensures that all affected will be considered.
A risk register (PRINCE2) is a document used as a risk management tool and to fulfill regulatory compliance acting as a repository for all risks identified and includes additional information about each risk, e.g., nature of the risk, reference and owner, mitigation measures. It can be displayed as a scatterplot or as a table.
Enterprise systems engineering (ESE) is the discipline that applies systems engineering to the design of an enterprise. As a discipline, it includes a body of knowledge, principles, and processes tailored to the design of enterprise systems.
Event chain methodology is a network analysis technique that is focused on identifying and managing events and relationship between them that affect project schedules. It is an uncertainty modeling schedule technique. Event chain methodology is an extension of quantitative project risk analysis with Monte Carlo simulations. It is the next advance beyond critical path method and critical chain project management. Event chain methodology tries to mitigate the effect of motivational and cognitive biases in estimating and scheduling. It improves accuracy of risk assessment and helps to generate more realistic risk adjusted project schedules.
A glossary of terms relating to project management and consulting.
The project management triangle is a model of the constraints of project management. While its origins are unclear, it has been used since at least the 1950s. It contends that:
The quality of work is constrained by the project's budget, deadlines and scope (features).
The project manager can trade between constraints.
Changes in one constraint necessitate changes in others to compensate or quality will suffer.
IT risk management is the application of risk management methods to information technology in order to manage IT risk, i.e.:
Within project management, risk management refers to activities for minimizing project risks, and thereby ensuring that a project is completed within time and budget, as well as fulfilling its goals.
Benefits Realization Management (BRM) is one of the many ways of managing how time and resources are invested into making desirable changes.
The following outline is provided as an overview of and topical guide to project management:
↑ PMI PMBOKr Chapter 11, Risk Management "Archived copy". Archived from the original on 2008-11-04. Retrieved 2008-11-12.{{cite web}}: CS1 maint: archived copy as title (link)
↑ Virine, L., & Trumper, M. Project Risk Analysis Made Ridiculously Simple. World Scientific Publishing. 2017
↑ Project Management Institute, Risk Management Special Interest Group (SIG), http://www.risksig.com/
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
