User:Agiloteam1/sandbox
Conventional vs Agile Project Risk Management
[edit]Risk
[edit]'Any situation involving exposure to danger is called Risk [1].’
Conventional Risk Management
[edit]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. Project Risk Management Process[2] can be understood by following diagram:
The Project Risk Management steps are explained next.
1. Plan Risk Management
[edit]Plan Risk Management is the process of defining how to conduct risk management activities for a project. The key benefit of this process is it ensures that the degree, type, and visibility of risk management are commensurate with both the risks and the importance of the project to the organization. The risk management plan is vital to communicate with and obtain agreement and support from all stakeholders to ensure the risk management process is supported and performed effectively over the project life cycle.
Tools & Techniques
[edit]The Tools & Techniques used in Risk Management Planning are as follows:
Analytical Techniques
[edit]Analytical techniques are used to understand and define the overall risk management context of the project. Risk management context is a combination of stakeholder risk attitudes and the strategic risk exposure of a given project based on the overall project context
Expert Judgment
[edit]Expert Judgment is a term that refers a specifically to a technique in which judgment is made based upon a specific set of criteria and/or expertise that has been acquired in a specific knowledge area, or product area, a particular discipline, an industry, etc. This knowledge base can be provided by a member of the project team, or multiple members of the project team,or by a team leader or team leaders.
Meetings
[edit]Project teams hold planning meetings to develop the risk management plan. Attendees at these meetings may include the project manager, selected project team members and stakeholders, anyone in the organization with responsibility to manage the risk planning and execution activities, and others, as needed.
2. Risk Identification
[edit]This step includes Identifying Risks which may affect the project and documenting their characteristics. The key benefit of this process is the documentation of existing risks and the knowledge and ability it provides to the project team to anticipate events.
Tools & Techniques
[edit]The Tools & Techniques used in Risk Identification are as follows:
Documentation Reviews
[edit]A structured review of the project documentation may be performed, including plans, assumptions, previous project files, agreements, and other information.
Information Gathering Techniques
[edit]Examples of information gathering techniques used in identifying risks can include:
- Brainstorming
- Delphi Technique
- Interviewing
- Root Cause Analysis
Checklist Analysis
[edit]Checklists contain historical information and knowledge that has been accumulated from previous similar projects and from other sources of information.
Assumptions Analysis
[edit]Every project and its plan is conceived and developed based on a set of hypotheses, scenarios, or assumptions. Assumptions analysis explores the validity of assumptions as they apply to the project.
SWOT Analysis
[edit]This technique examines the project from each of the strengths, weaknesses, opportunities, and threats (SWOT) perspectives to increase the breadth of identified risks by including internally generated risks.
3. Qualitative Risk Analysis
[edit]Qualitative Risk Analysis is the process of prioritizing risks for further analysis or action by assessing and combining their probability of occurrence and impact. The key benefit of this process is that it enables project managers to reduce the level of uncertainty and to focus on high-priority risks.
Tools & Techniques
[edit]The Tools & Techniques used for Qualitative Risk Analysis are as follows:
Probability and Impact Matrix
[edit]Risk probability assessment investigates the likelihood that each specific risk will occur. Risk impact assessment investigates the potential effect on a project objective such as schedule, cost, quality, or performance, including both negative effects for threats and positive effects for opportunities.
Risk Data Quality Assessment
[edit]Risk data quality assessment is a technique to evaluate the degree to which the data about risks is useful for risk management. It involves examining the degree to which the risk is understood and the accuracy, quality, reliability, and integrity of the data about the risk.
Risk Categorization
[edit]Risks to the project can be categorized by sources of risk (e.g., using the RBS), the area of the project affected (e.g., using the WBS), or other useful categories (e.g., project phase) to determine the areas of the project most exposed to the effects of uncertainty.
Risk Urgency Assessment
[edit]Risks requiring near-term responses may be considered more urgent to address. Indicators of priority may include probability of detecting the risk, time to affect a risk response, symptoms and warning signs, and the risk rating.
Expert Judgment
[edit]Expert judgment is required to assess the probability and impact of each risk to determine its location. Experts generally are those having experience with similar, recent projects.
4. Quantitative Risk Analysis
[edit]Quantitative Risk Analysis is the process of numerically analyzing the effect of identified risks on overall project objectives. The key benefit of this process is that it produces quantitative risk information to support decision making in order to reduce project uncertainty.
Tools & Techniques
[edit]The Tools & Techniques used for Quantitative Risk Analysis are as follows:
Data Gathering and Representation Techniques
[edit]Examples of Data Gathering Techniques are as follows:
- Interviewing
- Probability Distributions
Quantitative risk Analysis and Modeling techniques
[edit]Commonly used techniques use both event-oriented and project-oriented analysis approaches, including:
- Sensitivity Analysis
- Expected Monetary Value Analysis (EMV)
- Modeling and Simulation
Expert Judgment
[edit]Expert judgment (ideally using experts with relevant, recent experience) is required to identify potential cost and schedule impacts, to evaluate probability, and to define inputs such as probability distributions into the tools.
5. Risk Response Planning
[edit]Risk Response Planning is the process of developing options and actions to enhance opportunities and to reduce threats to project objectives. The key benefit of this process is that it addresses the risks by their priority, inserting resources and activities into the budget, schedule and project management plan as needed.
Tools & Techniques
[edit]The Tools & Techniques used in Risk Response Planning are as follows:
Strategies for Positive Risks or Threats
[edit]- Exploit: The exploit strategy may be selected for risks with positive impacts where the organization wishes to ensure that the opportunity is realized.
- Enhance: The enhance strategy is used to increase the probability and/or the positive impacts of an opportunity.
- Share: Sharing a positive risk involves allocating some or all of the ownership of the opportunity to a third party who is best able to capture the opportunity for the benefit of the project.
- Accept. Accepting an opportunity is being willing to take advantage of the opportunity if it arises, but not actively pursuing it.
Strategies for Negative Risks or Threats
[edit]- Avoid: Risk avoidance is a risk response strategy whereby the project team acts to eliminate the threat or protect the project from its impact.
- Transfer: Risk transference is a risk response strategy whereby the project team shifts the impact of a threat to a third party, together with ownership of the response.
- Mitigate: Risk mitigation is a risk response strategy whereby the project team acts to reduce the probability of occurrence or impact of a risk.
- Accept: Risk acceptance is a risk response strategy whereby the project team decides to acknowledge the risk and not take any action unless the risk occurs.
Contingent Response Strategies
[edit]Some responses are designed for use only if certain events occur. For some risks, it is appropriate for the project team to make a response plan that will only be executed under certain predefined conditions, if it is believed that there will be sufficient warning to implement the plan.
Expert Judgment
[edit]Expert judgment is input from knowledgeable parties pertaining to the actions to be taken on a specific and defined risk.
6. Risk Controlling
[edit]Risk Controlling is the process of implementing risk response plans, tracking identified risks, monitoring residual risks, identifying new risks, and evaluating risk process effectiveness throughout the project. The key benefit of this process is that it improves efficiency of the risk approach throughout the project life cycle to continuously optimize risk responses.
Tools & Techniques
[edit]The Tools & Techniques used in Risk Controlling are as follows:
Risk Reassessment
[edit]Control Risks often results in identification of new risks, reassessment of current risks, and the closing of risks that are outdated.
Risk Audits
[edit]Risk audits examine and document the effectiveness of risk responses in dealing with identified risks and their root causes, as well as the effectiveness of the risk management process.
Variance and trend Analysis
[edit]Different control processes employ variance analysis to compare the planned results to the actual results for the purposes of controlling risks, trends in the project’s execution should be reviewed using performance information.
Technical Performance Measurement
[edit]Technical performance measurement compares technical accomplishments during project execution to the schedule of technical achievement.
Reserve Analysis
[edit]Throughout execution of the project, some risks may occur with positive or negative impacts on budget or schedule contingency reserves.
Meetings
[edit]Project risk management should be an agenda item at periodic status meetings. The amount of time required for that item will vary, depending upon the risks that have been identified, their priority, and difficulty of response.
Agile Risk Management
[edit]Agile risk management is concerned with the identification, assessment, prioritization, treatment and monitoring of project risks in a manner consistent with agile principles and practices. It considers not only threats (negative risks) but also opportunities (positive risks) in the context of the enterprise attitude towards risk and employs its own techniques and practices to inform decision making to balance risk and reward.
Agile Risk Management Process
[edit]Agile Risk Management[3] is done in 4 steps:
Understand Project Objectives, Context and Risk Environment
[edit]This step is about achieving an understanding of the environment in which the project operates. This is a necessary prerequisite to frame risk management practices and assist in clarifying the relevance of risk within the project and in relation to the organization (e.g., the need for risk dispensations).
Risk Scoping (Identification of Risk Drivers & Appetite)
[edit]This step is performed by scoping the project risk drivers, the primary sources of risk and the institutional attitude towards and tolerance thereof can be established and communicated in a clear manner. This ensures the foundations for alignment of personal and institutional attitudes towards risk-reward behavior.
Risk Tailoring (Embedding Risk Management in Agile Process)
[edit]In this step the dynamic view of agile process being employed is charted in order to determine the most appropriate positioning of risk management activities (e.g., risk identification workshops at the start of an iteration and risk retrospectives at the end). In light of the risks facing a project, additional measures may also be proposed (e.g., application of specific agile techniques to tackle risk).
Risk Management (Identify, Analyze, Manage & Monitor)
[edit]This encompasses the operational aspects of risk management within the project. (e.g., use of risk modified Kanban boards to visualize the distribution of risk and reward, tagging of activities to indicate the application of an agile technique in order to treat risk and communal ownership of risk afterwards).
Scrum
[edit]Scrum is an iterative and incremental agile software development framework for managing projects[4] . It is most widely used practical application of agile project management. So it is really necessary to discuss risk management with respect to scrum.
Managing Risk in Scrum
[edit]The following picture describes an approach[5] to agile risk management that suits Scrum teams using a Kanban board approach (also known as a Scrum-ban) in their work.
Risk Identification
[edit]Identification of risks is hardest step in Risk Management process. The biggest problem is conflating uncertainties and their effects. A simple but effective technique for risk identification is to brainstorm what might occur (effects) and then in each case, ask why it might occur (risks). Once identified risks should be recorded in a risk log (e.g., description, inherent risk exposure) to which will be added further information (e.g., risk response strategy and treatment, residual risk exposure) later.
Risk Analysis, Prioritization & Treatment
[edit]The purpose of risk analysis is to determine a course of action and prioritize it accordingly. Risks should be assessed in terms of likelihood and impact (together these are known as risk exposure) which need to be scaled (i.e., S, M, L). As a first step, the risk as originally encountered (inherent risk) should be estimated and later reassessed once a treatment has been determined (residual risk). Sometimes the treatment of risk introduces entirely new risks (secondary risks) and thus risks in practice are linked in a complex web of causality. Bear in mind, that range estimates of risk exposure components are perfectly acceptable if these serve as the basis for discussion within the team. It is important to understand the limitations of risk assessment techniques such as asking people (e.g., hidden agendas, confirmation bias), using past data (e.g., might not be indicative of future trends) or probability models (e.g., hidden assumptions) so whenever an assessment is made, it should be challenged. It is a common misconception that high risk must imply high reward. In fact, what should really be asked is whether or not the reward implied by a story or task warrants the level of risk it entails.
Just like conventional project management following risk response strategies are commonly used in agile risk management:
- Accept Undertake no action to manage the risk, but instead have a contingency plan in place in the event that the risk is realized.
- Exploit/Reduce Enact measures to increase/decrease either the likelihood or the impact of the risk.
- Share/Transfer Endeavor to share/transfer the risk to other parties in exchange for a share in the rewards or a fee for assuming the risks.
- Avoid Refrain from taking part in the task that gave rise to the risk.
Once a strategy has been determined the next step in agile is to determine concrete measures to treat the risk. The following options are available:
- Do nothing (but plan) except that the risk might occur and think about what would need to be done if it were realized. This becomes an optional task on the Kanban which might never be needed.
- Risk Tasking Create a task that deals with the risk (e.g., exploit, reduce, share or transfer it). These tasks are just like any other task in Sprint planning. It is very helpful to color code such tasks (e.g., red for reduction, green for exploitation) so that the distribution of risk and reward can be visualized on the Kanban board.
- Risk Tagging This refers to the selection of an agile technique specifically chosen to cater for a risk (e.g., pair programming) and which is applied to a class of activities (e.g., all GUI related tasks). Tagging involves placing a mark next to each affected task to remind the team of the technique to be applied.
- Task Dropping Remove the task from the Kanban that is giving rise to the risk.
Risk Monitoring
[edit]Risk monitoring provides a visual cue of what is being done to tackle risk whilst at the same time acknowledging the systemic nature of risk within the project.
Risk monitoring requires the assigning of scores to risk exposure bands when assessing both inherent and residual risks. For example, the inner region of the risk response strategies chart might be assigned two points, the middle four and outer six. The amount of risk mitigated thus reflects the difference between inherent and residual risk scores and serves as the basis of a risk burn-down for the Sprint.
Conventional vs Agile Project Risk Management
[edit]Now this section is to highlight was on where and what are the differences between the two methodologies. It is very important to not treat the risk management approach of Agile the same way as Conventional Project Management as the working process of both the methodologies is very different. Risk management in Agile takes on a more active and reactive role which is important to factor into daily activities. In Conventional Risk Management we spend more time on planning and we have longer projects or more stable environments, where requirements don’t change that often. In traditional project management, approach to Risk management is important, but it is not as active or ever present as we find in an agile environment.
Difference between Conventional vs Agile Project Risk Management
[edit]Project Risk Management differs in both project management techniques as their process varies from one another.
Risk Management in both the techniques in different project management perspectives is explained below:
Project Risk Planning
[edit]In Conventional Project Management, we do more up front planning, including risks, whereas in Agile, risk management is done by using the same iterative approach of agile processes.
Project Risk Identification
[edit]Good Project Management involves risk identification at every stage and it is done in both Conventional and Agile methodologies. Both approaches use the same process of Identify, Quantify, Prioritize, Plan and Manage approach, and they appear to be very similar. The more iterative approach for Agile, allows risks to be surfaced and addressed on daily basis (using Scrum), but in conventional project management, only the largest risks are usually identified and planned around. In traditional projects, risks tend to be more predictable (they don’t suddenly appear), but in technical projects we tend to have more unknown risks, and so the need is for more dynamic risk management.
Project Risk Management Tools
[edit]The tools that are required in risk management in Conventional and Agile project management are almost same except the few that are associated with the methodology of process. Both the methods use Risk Registers which is a world-wide acceptable methodology of registering the risks occurring in projects.
Risk Comparison Summary
[edit]Both the methodologies find their application in their fields and have a very wide use dependent upon the nature of projects. The risks can be identified using both the methodologies but a key difference in agile projects is that risks identified can be more technical in nature. The reason for this is because the agile risk management involves continuous monitoring and reviewing of processes and hence the risks are being surfaced and resolved continuously.[6]
Reference
[edit]- ^ https://en.oxforddictionaries.com/definition/risk
- ^ http://www.cs.bilkent.edu.tr/~cagatay/cs413/PMBOK.pdf
- ^ https://pdfs.semanticscholar.org/e552/cfb442720b6d5de8c13bb148db2582bc0877.pdf
- ^ https://en.wikipedia.org/wiki/Scrum_(software_development
- ^ https://en.wikipedia.org/wiki/Scrum_(software_development
- ^ https://pmi-portland.org/resources/newsletter/newsletter-article-archive/675-risk-management-agile-v-waterfall