All Courses
Login / Sign up
Get started

By signing up, you agree to our Terms of Use and Privacy Policy.
Reset your password
Enter your email and we'll send you instructions on how to reset your password.

Risk Management

The objectives of Project Risk Management are to increase the probability and impact of positive events and decrease the probability and impact of events adverse to the project. The process of identification, analysis and either acceptance or mitigation of uncertainty in investment decision-making. Essentially, risk management occurs anytime an investor or fund manager analyzes and attempts to quantify the potential for losses in an investment and then takes the appropriate action (or inaction) given their investment objectives and risk tolerance. Inadequate risk management can result in severe consequences for companies as well as individuals. For example, the recession that began in 2008 was largely caused by the loose credit risk management of financial firms.

Agile Risk Management: 5 Core Steps

There is no definite consensus on the need for risk management within the Agile method. This has led many to believe that risk management is irrelevant in an iterative model. Some follow the approach of ignoring risks until they manifest into issues; then they manage them through the natural sprint progression. I feel it's better to manage risks proactively in Agile.

The Risk Management Methodology is been outlined into five Steps:

  • Identify

  • Classify

  • Quantify

  • Plan & Act

  • Review

The risk management methodology steps are as follows:

Risk Identification

The objectives of risk identification are to identify and categorize risks that could affect the project and document these risks. The outcome of risk identification is a list of risks. What needs to be done with the list of risks depends on the nature of the risks and the project. The items can then be assigned to individual team members to watch throughout the project development process and used for risk allocation purposes. The risks can feed the rigorous process of assessment, analysis, mitigation and planning, allocation, and monitoring and updating.

The risk identification process should stop short of assessing or analyzing risks so that it does not inhibit the identification of "minor" risks. The process should promote creative thinking and leverage team experience and knowledge. In practice, however, risk identification and risk analysis are often completed in a single step, a process that can be called risk assessment. For example, if a risk is identified in the process of interviewing an expert, it is logical to pursue information on the probability that it will occur, its consequences/impacts, the time associated with the risk (i.e., when it might occur), and possible ways of dealing with it. The latter actions are part of risk assessment, but they often begin during risk identification. The risk identification process begins with the team compiling the project's risk events.

The identification process will vary, depending on the nature of the project and the risk management skills of the team members, but most identification processes begin with an examination of issues and concerns created by the project development team. These issues and concerns can be derived from an examination of the project description, work breakdown structure, cost estimate, design and construction schedule, procurement plan, or general risk checklists. Checklists and databases can be created for recurring risks, but project team experience and subjective analysis almost always will be required to identify project specific risks.

 The team should examine and identify project events by reducing them to a level of detail that permits an evaluator to understand the significance of any risk and identify its causes, (i.e., risk drivers). This is a practical way of addressing the large and diverse numbers of potential risks that often occur on highway design and construction projects. Risks are those events that team members determine would adversely affect the project.

Risk Identification process starts with the beginning of the project and the same is being carried forward throughout the life of the project like :

  • Requirements Gathering

  • Planning Poker

  • Iteration Planning

  • Daily Stand Up

  • Iteration Review

  • Iteration Retrospective

  • Any risk has two dimensional influences.

The first Helpful/Harmful is a simple assessment of factors that have a potentially positive or negative influence on the success of project:

Helpful: Factors that advance the objectives of the project

Harmful: Factors that hinder or imperil the outcome of the project.

The second dimension of Risk is the identification of the source of the Risk:

Internal: Factors originating inside the organization or within the sphere of influence of the project.

External: Factors originating outside of the organization or project that cannot usually be influenced by the project. Combining these factors into a two dimensional assessment provides us with the classic SWOT Analysis view of our project: Strengths, Weaknesses, Opportunities, and Threats.

Risk Classification

After the risks are identified, they should be classified into groups of like risks. Classification of risks helps reduce redundancy and provides for easier management of the risks in later phases of the risk analysis process. Classifying risks also provides for the creation of risk checklists, risk registers, and databases for future projects. Each of the Risks needs to be categorized as to the affected area, likelihood and level of Impact it may have on the project. Risk Classes are used primarily for organizing, summarizing and reporting of Risks to management and stakeholders. Some Risks you identify may impact more than one Class, and if they do, they should be reflected in the summaries of those Classes. Some of the risk classes which can be used for the classification are

  • Solution: Does it satisfy end user requirements (quality, features, performance, etc…)

  • Timeline: Is the project on time

  • Budget: Is the project within its budget and/or is there sufficient budget to complete the project

  • Privacy: Does the solution comply with privacy legislation and the company’s own privacy policy

  • Security: Is the solution adequately protected from intruders

  • Resources: Are there sufficient skilled resources available to complete the project

  • Scope: Is project scope properly contained



0 Comments

Add Comment

Subject to Moderate