What is mean Risk Identification and it's impact on the Project teams?

Definition: Risk impact assessment is the process of assessing the probabilities and consequences of risk events if they are realized. The results of this assessment are then used to prioritize risks to establish a most-to-least-critical importance ranking. Ranking risks in terms of their criticality or importance provides insights to the project's management on where resources may be needed to manage or mitigate the realization of high probability/high consequence risk events. Keywords: risk, risk impact assessment, risk management, risk prioritization MITRE SE Roles & Expectations: MITRE systems engineers (SEs) working on government programs are expected to analyze risks with respect to impact, probability, dependencies, and timeframes and to prioritize risks to facilitate decision making by the sponsor or customers [1]. Background Risk impact assessment and prioritization are the second and third steps of the process depicted in Figure1 [2]. Figure1. Risk Management: Fundamental Steps Figure1. Risk Management: Fundamental Steps Risk Impact Assessment in the Systems Engineering Program In this step, the impact each risk event could have on the project is assessed. Typically this assessment considers how the event could impact cost, schedule, or technical performance objectives. Impacts are not limited to these criteria, however; political or economic consequences may also need to be considered. The probability (chance) each risk event will occur is also assessed. This often involves the use of subjective probability assessment techniques, particularly if circumstances preclude a direct evaluation of the probability by objective methods (i.e., engineering analysis, modeling, and simulation). Chapters2 and4 of Garvey [2] discuss the topic of subjective probability assessments, as well as criteria for assessing a risk event's impact or consequence to a project. As part of the risk assessment, risk dependencies, interdependencies, and the timeframe of the potential impact (near-, mid-, or far-term) need to be identified. The MITRE-developed RiskNAV® tool is an example of a tool that can help perform this assessment. For additional details, see the Risk Management Tools article in this Guide. When assessing risk, it is important to match the assessment impact to the decision framework. For program management, risks are typically assessed against cost, schedule, and technical performance targets. Some programs may also include oversight and compliance, or political impacts. Garvey [2] provides an extensive set of rating scales for making these multicriteria assessments, as well as ways to combine them into an overall measure of impact or consequence. These scales provide a consistent basis for determining risk impact levels across cost, schedule, performance, and other criteria considered important to the project. In addition, the Risk Matrix tool can help evaluate these risks to particular programs (see the Risk Management Tools article). Performing POET (Political, Operational, Economic, Technical) and/or SWOT (Strengths, Weaknesses, Opportunities, and Threats) assessments can help determine the drivers of the risks. For more details on these analyses, see the Tools to Enable a Comprehensive Viewpoint article in the Comprehensive Viewpoint topic of the Enterprise Engineering section. For some programs or projects, the impacts of risk on enterprise or organizational goals and objectives are more meaningful to the managing organization. Risks are assessed against the potential negative impact on enterprise goals. Using risk management tools for the enterprise and its components can help with the consistency of risk determination. This consistency is similar to the scale example shown below, except that the assessment would be done at the enterprise level. Depending on the criticality of a component to enterprise success (e.g., risk of using commercial communications to support a military operation and the impact of the enterprise to mission success, versus risk of using commercial communications for peacetime transportation of military equipment), the risks may be viewed differently at the enterprise level even when the solution sets are the same or similar. One way management plans for engineering an enterprise is to create capability portfolios of technology programs and initiatives that, when synchronized, will deliver time-phased capabilities that advance enterprise goals and mission outcomes. A capability portfolio is a time-dynamic organizing construct to deliver capabilities across specified epochs; a capability can be defined as the ability to achieve an effect to a standard under specified conditions using multiple combinations of means and ways to perform a set of tasks [2]. With the introduction of capability management, defining the impact of risk on functional or capability objectives may provide valuable insights into what capability is at risk, and which risks could potentially significantly impact the ability to achieve a capability and/or impact multiple capability areas. In portfolio management, a set of investments is administered based on an overall goal(s), timing, tolerance for risk, cost/price interdependencies, a budget, and changes in the relevant environment over time. These factors are generally applicable to the government acquisition environment (see the Guide article Portfolio Management in the Enterprise Engineering section). For portfolio risk assessment, investment decision, or analysis of alternatives tasks, using categories of risk area scales may be the most appropriate way to ensure each alternative or option has considered all areas of risk. Risk areas may include advocacy, funding, resources, schedule and cost estimate confidence, technical maturity, ability to meet technical performance, operational deployability, integration and interoperability, and complexity. Scales are determined for each risk area, and each alternative is assessed against all categories. Risk assessment may also include operational consideration of threat and vulnerability. For cost-risk analysis, the determination of uncertainty bounds is the risk assessment. When determining the appropriate risk assessment approach, it is important to consider the information need. Shown below are Probability of Occurrence, Program Risk Management Assessment Scale, and Investment Risk Assessment Scale examples used in MITRE's SE work with government sponsors or clients. RiskNav Probability of Occurrence Example1.00 Issue:1 Certain to occur0.95-0.99 High: >0.95 <1 Extremely sure to occur0.85-0.95 High: >0.85 <=0.95 Almost sure to occur0.75-0.85 High: >0.75 <=0.85 Very likely to occur0.65-0.75 High: >0.65 <=0.75 Likely to occur0.55-0.65 Medium: >0.55 <=0.65 Somewhat greater than an even chance0.45-0.55 Medium: >0.45 <=0.55 An even chance to occur0.35-0.45 Medium: >0.35 <=0.45 Somewhat less than an even chance0.25-0.35 Low: >0.25 <=0.35 Not very likely to occur0.15-0.25 Low: >0.15 <=0.25 Not likely to occur0.00-0.15 Low: >0.00 <=0.15 Almost sure not to occur Table1. Program Risk Management Assessment Scale Example Table1. Program Risk Management Assessment Scale Example Table2. Example of the Investment Risk Assessment Scale Technical Maturity Technical Performance Integration/Interoperability Details Maturity of technologies associated with the alternative Confidence in performance expectations This refers to Integration and Interoperability (I&I) issues as they affect the alternative's ability to achieve its stated outcome. The extent that I&I is understood has been demonstrated. It is assumed I&I considerations associated. Low Key technologies are ready and mature and require little/no effort in time to execute the alternative There are no technical or performance expectations identified that will have any impact on achieving the stated outcome objectives expected from the alternative For this alternative, I&I considerations are well understood. Most of the challenging concerns have been resolved and/or successfully tested/demonstrated under representative or actual field conditions. As such, I&I considerations are not expected to have severe negative impact on the ability of this alternative to achieve its stated objectives. Low med Key technologies are expected to be ready and mature in time to execute the alternative Limited technical or performance expectations identified that will have a minor impact on achieving the stated outcome objectives expected from the alternative For this alternative, I&I considerations are very well understood. Some challenging concerns have not been resolved and/or successfully tested/demonstrated under representative or actual field conditions. As such, I&I considerations are expected to have negligible impact on the ability of this alternative to achieve its stated objectives. Medium Key technologies are not ready and mature and require moderate effort to implement the alternative Technical or performance limitations have been identified that will have a moderate impact on achieving the stated outcome objectives expected from the alternative For this alternative, I&I considerations are somewhat-borderline understood. Nearly all (including the most challenging concerns) have been resolved and/or successfully tested/demonstrated under representative or actual field conditions. As such, I&I considerations are expected to have modest negative effects on the ability of this alternative to achieve its stated objectives. Medium-High Key technologies are not ready and mature and require significant effort to implement the alternative There are no technical or performance expectations identified that will have any impact on achieving the stated outcome objectives expected from the alternative For this alternative, I&I considerations are somewhat-borderline understood. Nearly all (including the most challenging concerns) have been resolved and/or successfully tested/demonstrated under representative or actual field conditions. As such, I&I considerations are expected to have significant negative effects on the ability of this alternative to achieve its stated objectives. High Key technologies will not be ready and mature and will have a severe impact on the alternative Major technical or performance issues have been identified that will have a severe impact on achieving the stated outcome objectives expected from the alternative For this alternative, I&I considerations are not very well understood. Many challenging concerns are not resolved and/or successfully tested/demonstrated under representative or actual field conditions. As such, I&I considerations are expected to have severe negative effects on the ability of this alternative to achieve its stated objectives. Catastrophic Key technologies will not be available and there is no alternative Serious technical or performance issues have been identified that will prevent achieving any of the stated outcome objectives expected from the alternative For this alternative, I&I considerations are show-stoppers with the respect to the ability of this alternative to achieve its stated objectives. Risk Prioritization in the Systems Engineering Program In the risk prioritization step, the overall set of identified risk events, their impact assessments, and their probabilities of occurrences are "processed" to derive a most-to-least-critical rank-order of identified risks. A major purpose of prioritizing risks is to form a basis for allocating resources. Multiple qualitative and quantitative techniques have been developed for risk impact assessment and prioritization. Qualitative techniques include analysis of probability and impact, developing a probability and impact matrix, risk categorization, risk frequency ranking (risks with multiple impacts), and risk urgency assessment. Quantitative techniques include weighting of cardinal risk assessments of consequence, probability, and timeframe; probability distributions; sensitivity analysis; expected monetary value analysis; and modeling and simulation. MITRE has developed the min- and max-average approaches (using a weighting scale more heavily weighting the max or min value). Expert judgment is involved in all of these techniques to identify potential impacts, define inputs, and interpret the data [3]. In addition, MITRE has developed the RiskNAV® tool that assists managers in assessing and prioritizing program risks. RiskNav includes the ability to weight timeframe in the risk ranking (e.g., how much time to react/potentially mitigate). RiskNav is used by a number of MITRE sponsors and customers. For detailed information on RiskNav, refer to the article

Project Risk Identification

Project Risk Management includes the processes of conducting risk management planning, identification, analysis, response planning, and controlling risk on a project. The objectives of project risk management are to increase the likelihood and impact of positive events, and decrease the likelihood and impact of negative events in the project.[PMBOK]

Project Risk identification is the most important process in the Risk Management Planning. Risk Identification determines which risks might affect the project and documents their characteristics. However, as recommended by [Donna Ritter], we should not spend too much time in identifying risks. After the list is made, qualitative and quantitative analysis is done to figure out which risks you spend time and/or money on.

As stated in [PMBOK], there are some specific tools and techniques for identifying risk as listed below:

1. Documentation Reviews
2. Information Gathering Techniques - Brainstorming, Delphi Technique, Interviewing, Root cause analysis
3. Checklist analysis - previous similar project, lowest level RBS
4. Assumption analysis
5. Diagramming Techniques - cause and effect diagram, system and process flow chart, influence diagrams
6. SWOT Analysis
7. Expert Judgment

The risk identification method suggested in this article is to compliment the existing tools and techniques recommended by PMBOK.

The common Project Risk List Reference below which are divided into a number of risk categories are samples of potential risks of a project may be exposed to and should only be used by the Project Team as a reference and starting point for risk identification during the project risk management planning.

Risk Category : Schedule

1. Schedule not realistic, only "best case".
2. Important task missing from the schedule.
3. A delay in one task causes cascading delays in dependent tasks.
4. Unfamiliar areas of the product take more time than expected to design and implement

Risk Category : Requirement Risk

1. Requirements have been base lined but continue to change.
2. Requirements are poorly defined, and further definition expands the scope of the project
3. Specified areas of the product are more time-consuming than expected.
4. Requirements are only partly known at project start
5. The total features requested may be beyond what the development team can deliver in the time available.

Risk Category : Project Management Risk

1. PM has little authority in the organization structure and little personal power to influence decision-making and resources
2. Priorities change on existing program
3. Project key success criteria not clearly defined to verify the successful completion of each project phase.
4. Projects within the program often need the same resources at the same time
5. Date is being totally driven by need to meet marketing demo, trade show, or other mandate; little consideration of project team estimates

Risk Category : Product/Technology Risk

1. Development of the wrong user interface results in redesign and implementation.
2. Development of extra software functions that are not required (gold plating) extends the schedule.
3. Requirements for interfacing with other systems are not under the team’s scope.
4. Dependency on a technology that is still under development lengthens the schedule.
5. Selected technology is a poor match to the problem or customer

Risk Category : Customer Risk

1. Customer insists on new requirements.
2. Customer review/decision cycles for plans, prototypes, and specifications are slower than expected.
3. Customer insists on technical decisions that lengthen the schedule.
4. Customer will not accept the software as delivered even though it meets all specifications.
5. Customer has expectations for development speed that developers cannot meet.

Risk Category : Human Resources & Contractors Risk

1. Critical development work is being performed by one developer
2. Some developers may leave the project before it is finished.
3. Hiring process takes longer than expected.
4. Personnel need extra time to learn unfamiliar software tools, hardware and programming language.
5. Contract personnel leave before project is complete.
6. Conflicts among team members result in poor communication, poor designs, interface errors and extra rework.
7. Personnel with critical skills needed for the project cannot be found.
8. Contractor does not deliver components when promised.

Conclusion

Risk Identification in the project is critical in order to manage and complete the project successfully. The earlier the risk can be identified, the earlier the plan can be made to mitigate the effects of the potential risks. There are a lot of tools and techniques or method available to identify the project risks. The method suggested in this article will complement the existing risk identification method to get a more comprehensive risk list for Risk Management Planning. Identifying the risk is an iterative process, and the entire project team should be involved from the beginning of the project. Comprehensive and good risk identification will produce a good project results.

I am agree with answer of mr. vinod

 

 

I agree with Mr. Vinod Jetley  good answer. Thank you.

I am agree with answer of mr. vinod

______________________________________

Answers have provided enough details about that ... Thank You

Risk Assessment and Management Planning

a. Identify risks

Risk identification involves brainstorming the possible threats to the project. The project manager is responsible for having the project team assist in identifying these risks.

b. Risk Assessment

The probability of occurrence is the degree of belief that various events or effects will occur. For each risk that is identified, there must be a determination of how likely it is that the risk will happen. A cardinal (1 - low to10 - high) or ordinal (high, medium, low) scale may be used.

The potential severity of impact or consequence determines the significance of the risk. This is an assessment of how great an impact the event will have if it happens. Quantitative methods might include monetary costs or time estimates that can be associated with the impact. Qualitative methods may be simply high, medium, or low estimates. The cardinal and ordinal scale would be similar to those used for probability.

The project manager should organize and prepare for a risk meeting that is separate from project detailed planning meeting.

To begin, the project manager should prepare and distribute the assessment agenda. In planning for this meeting, be sure to allow at least four hours. The project manager should also identify a separate facilitator since the project manager will actively participate in this meeting. Senior management should not participate in initial risk assessment meetings so the project team is not inhibited to openly discuss and assess all risks and impacts to the project.

Before the meeting, make sure the following items have been arranged or prepared:

ô Meeting room

ô Overhead projector

ô Computer with a spreadsheet program

ô Agenda distributed at least two days in advance

ô On the day of the meeting, list the risk attributes separately on flip chart paper and post around the room.

Kick off the risk meeting with a review of the project charter and any critical issues, milestones, or assumptions that have already been determined. In addition, describe the attributes listed on the flip charts to encourage participants to begin thinking of possible risks. Because this initial risk meeting is used to gain feedback from the entire team, it is important to make sure each participant feels unrestricted in identifying and assessing any risks. Once you have set the stage for he meeting proceed as follows:

ô Have each participant go around the room listing risks on each of the attribute flip charts posted before the meeting.

Have the recorder enter each risk listed into a Risk Planning Spreadsheet organized by attribute.

ô Each participant is given a printed copy of the spreadsheet and asked to rate from1 to10 (1 – low to10 – high) the probability of occurrence and the consequence if the risk event occurs.

ô Collect the sheets and enter them into the spreadsheet so an average score can be obtained for both the probability and consequence.

ô Plot each risk, based on the average probability and consequence on a graph as follows:

Consequenc

1

D

C

B

E

A

10

Probability

1

10

ô Review the results with the team to gain concurrence on each risk. Where significant differences occurred in individual scoring, discuss in detail the reasons for the difference.

ô Next, prioritize the risks as a group from the most important to the least important. Assign ownership to each risk.

ô Select the top5 –10 priority risks (depending on the total number.) Enter these risks into the Risk Priorities List. These risks will have detailed plans developed that will help you manage the consequence of the risk. For all of the other risks, detailed plans will not be developed, but they likewise must be reviewed periodically to ensure the do not become a higher priority risk.

Adjourn the meeting with clearly defined deliverables, with completion dates, that will result from the development of the risk plans for the selected top priority risks. Owners should develop the risk plans using the Risk Management Plan.

c. Develop Risk Management Plans

The assigned owners will develop detailed Risk Management Plans, which include mitigation strategies and contingency plans, on the highest priority risks. Not all risks warrant a mitigation strategy. Depending upon the probability of occurrence, potential losses and frequency, and/or time available for planning, the project manager and team members will decide if a mitigation strategy is necessary.

The prioritized risk list is used as input into developing a risk strategy. There are four basic risk strategies:

ô Risk avoidance is eliminating the risk threat. An example would be planning a company picnic. The threat of rain is a risk if the event is held outside. One way to avoid this risk is to hold the event indoors or under tents.

ô Risk mitigation is determining how to decrease the probability of the risk and/or reduce its impact. Risk mitigation involves lessening or reducing the probability of a risk event, its impact, or both.

ô Risk acceptance is understanding the risk and accepting the consequences should the risk occur. An example would be accepting extended project duration due to resource availability.

ô Risk transfer is shifting the risk to someone else. An example would be hiring a subcontractor to handle toxic waste rather than exposing the company’s employees to the hazardous materials.

A contingency plan for a risk event is the identification of steps that will be accomplished if the risk strategy is implemented. The steps will be included in the project’s schedule and cost baselines. Make sure the WBS reflects the deliverables required by the contingency plan.

Use the Risk Management Plan to develop detailed Risk Management Plans. The template is designed to provide a comprehensive assessment of each risk and the mitigation/contingency plan in the event the risk occurs. Once the Plan has been developed the project manager will consolidate the plans and ensure any needed deliverables are added to the WBS.

d. Obtain Risk Management Plan Approval

The project manager is responsible for reviewing the Risk Management Plan with the owner and obtaining the owner’s approval. During this meeting, the project manager must be clear on what risks are associated with the project and the impact if they occur. The project owner must understand the costs in terms of dollars, quality, and timeliness that risks have on the project.

 

Extracted from the Project Management Step-By-Step Guide

With my best regards specifically for the old Bayt.com customers !

 

I fully agree with the answers been added by EXPERTS................. Thanks.

With answer of A. Vinod Jetley .

...............................................................................

I agree with Mr. Vinod and Khaled answers.

Thanks for invitation, and I am really sorry for my late, because I were  had a lot of work.