tempus software engineering project management se603 unit 6: risk management egypt, 15.6.2015
DESCRIPTION
3 Objectives To get acquainted with the risk management framework Going through various risk response techniques Be familiar with the modified versions of AON that consider risk in their estimations (3-point AON Estimation)TRANSCRIPT
Tempus
Software Engineering Project Management SE603
Unit 6: Risk Management
Egypt, 15.6.2015
2
Introduction
Each software project is subject to various risks that might hinder its progress. This risk might result in severe consequences that could be huge financial loss. In order to manage these risks, risk management framework is adopted. firstly we identify the possible risks that might pop up along the project execution. Secondly, risk are assessed and prioritized according to many attributes such as impact and probability of occurrence. That is done through Risk Analysis and prioritization. Thirdly, certain responses should be considered to mitigate the impact of each risks though Risk Planning. Risk planning must be completed early during the project planning. Finally, along the development life cycle, risks are monitored and updated to make sure they are in control and the steps taken in the risk planning phase are effective and efficient.
In this unit, we investigate the risk management framework across its different phases and examine the indicators used to prioritize and asses risks. Besides, going through the 3-point AON Estimation - the modified version of AON illustrated in unit 4 – where this version consider risks in calculations.
3
Objectives
• To get acquainted with the risk management framework• Going through various risk response techniques• Be familiar with the modified versions of AON that consider
risk in their estimations (3-point AON Estimation)
4
Unit 6: List of topics
1. Risk Types 2. Risk Management Framework
2.1. Risk Identification2.1.1. Checklists 2.1.2. Brainstorming 2.1.3. Causal Mapping
2.2. Risk Analysis 2.3. Risk Response
2.3.1. Risks Acceptance2.3.2. Risks Avoidance2.3.3. Risks Reduction2.3.4. Risk Transfer2.3.5 Risk Mitigation2.3.6. Risk Escalation
2.4. Risk Monitoring3. 3-point AON Estimation
Risk Management
5
Step 0 Initiation
Step 1: Defining Scope and Objectives
Step 2: Understanding Client infrastructure
Step 3 Project Characteristics
Analysis
Step 4 Identifying deliverables
Step 5 Effort Estimation
Step 6 Handling risks
Step 7 Resources Allocation
Step 8 Plans ReviewStep 9 Plans Execution
Step 10 Low-Level Planning
For Each activity
review
Lower leveldetail
In order to handle project risks, step 6 of Step Wise Planning, introduced in Unit 2, is investigated.
Step 6 aims to enable project managers to have their risk management plans tuned to their software projects. The managers go through the risk identification process, followed by analyzing these risks. Once they are done of the analysis, they investigate the best possible response for each risk and finally keep an eyes on all risks make sure they are in control.
Figure: STEP WISE Planning Steps [1]
1. Risk Types (1/3)
6
Risk is unplanned event causing adverse effect on the project course resulting in extending the completion time, amplifying costs and confusing schedules of resources. There are 3 major types of risks [1]:
Project Risk Technical Risks Business Risks
Definition This type hinders achieving the project objectives causing drifts in schedule and budget.
This type is related to the software development phases affecting the quality and deadline of the software being developed.
This type of risk is related to the possibility of the product not meeting the requirements. Two types of risks: expected and unexpected.
Example Unexpected costs Unrealistic schedules Staff problems
Hi-end tools and languages imposing high risks such as unknown bugs and the compatibility issues
For Expected Risks: Changes in the market, exchange rate variations, taxes, etc.For Unexpected Risks: natural disasters, regulation and legalities changes, etc.
1. Risk Types (2/3)
7
Risks could be positive or negative. Negative risks are unwanted event causing adverse effects. Examples of Negative Risk is the main programmer is quitting the job or the unavailability of certain software tool or equipment.
Whilst, positive risks, are opportunities that positively affect the project, such as increasing ROI or finishing the project ahead of time. Example of Positive Risks: having number of subscribers on the launch date of a telecom service than expected.
1. Risk Types (3/3)
8
Positive risks could create negative risks. In the case of the telecom service, negative risks may arise the time switches were unable to handle the load or the billing system couldn’t process all the calls. Such negative risks can cause the whole service to fail resulting in low customer satisfaction. [12]
Negative risks have to be managed to mitigate their effects. However, positive risks are managed to take advantage of their occurrence. [12]
2. Risk Management Framework
9
The management framework is tailored to meet the scope of the software project of interest. The stages of the framework are [2]:
• Risk Identification • Risk Analysis • Risk Response ( Risk Acceptance / Avoidance /
Transfer / Escalation / Mitigation)• Risk Monitor and Control
Risk Management Flow
Identify Risk
Reject Risk
Close Risk
Conduct Risk Analysis
Reject Risk
Continue Risk Management
Transfer or Escalate
Close Risk
Develop Mitigation Strategies
Execute Mitigation Strategies
Develop Contingency
Strategies
Continuous Monitor and control Risk
Initial Accepta
nce
Is Risk Valid
Transfer Escalate
Accept Risk
Consequenc
es
Risk Still
Valid
Mitigation
Strategies
Required
Has Risk been
mitigated
Has risk
occurred
Contingency
strategies
required
Do contingency strategies
exist
Go to issue Management
Enter
No
Yes
Yes
No
No
Yes
Yes
No
Yes
No
No
Yes
Yes
No
Yes
No
Yes
No
Yes
Risk management continues by new owners of the risk
Due to continuous monitoring is the risk still valid?
When risks occur they become issues and are managed as issues
Alfred (Al) Florence The MITRE Corporation [2]
2.1. Risk Identification
11
The precaution actions are highly recommended to mitigate and avoid the impact of risks. Therefore, we firstly identify all possible risks that might occur throughout the project course to make sure they are in control. There are many approaches to identify risks such as [1]:
• Checklists• Brainstorming• Causal mapping
2.1.1. Checklists
12
Risk checklists include all risks with high probability of occurrence collected throughout years of experience in the domain of software development. Such checklists are organized and categorized by the development phases [3,8]:
• System Requirements Phase• Software Planning Phase• Software design phase • Implementation phase.
2.1.1. Checklists
13
Most technical and managerial related project members such as project manager, system engineer, software technical lead and developers, and the software engineers fill and review these checklists. Checklist must be revisited in each lifecycle stage to make sure that the listed risks are in control and no new risks were developed [3,8].
The following 4 slides display the (SEI) Software Risk Checklist [3], the most famous Software Project Risks [11] and Sample of Boehm’s top 10 development risks [10].
System Requirements Phase RISK Yes/No
Accept/ Work
Are system-level requirements documented? Is there a project-wide method for dealing with future requirements changes? Have software requirements been clearly delineated/allocated? Have the system-level software requirements been reviewed, inspected with system engineers, hardware engineers, and the users to insure clarity and completeness? Is an impact analysis conducted for all changes to baseline requirements? Software Planning Phase Have the end user requirements been represented in the concept phase? Are roles and responsibilities for software clearly defined and followed? Is the level of expertise for software language, lifecycle, development methodology (Formal Methods, Object Oriented, etc.), equipment (new technology), etc. available:Training: Is there enough trained personnel? Is there enough time to train all personnel? on equipment/ software development environment, etc.? Will there be time and resources to train additional personnel as needed? Budget: Is the budget sufficient for: equipment? needed personnel? Training?
Example of Software Engineering Institute (SEI) Software Risk Checklist – Taxonomy (1/2) [3]
14
System Requirements Phase RISK Yes/No
Accept/ Work
Is the software management plan being followed? Any updates needed?Are standards and guidelines sufficient to produce clear design and code?Will there be a major loss of personnel (or loss of critical personnel)?Is there a need to create simulators to test software?Software Implementation PhaseIs there auto-generated code?Are implementation personnel familiar with the development environment, language, and tools?Is the software management plan still being used? Is it up-to-date?Are there coding standards?Is the schedule being maintained? Have impacts been accounted for (technical, resources, etc.)? Is it still reasonable?
Example of Software Engineering Institute (SEI) Software Risk Checklist – Taxonomy (2/2) [3]
15
Software Project Risks [11]
16
AUTHOR(YEAR) DIMENSION OF RISKS NUMBER OF SOFTWARE RISKS
McFarlan (1981) 3 54 Boehm (1991) 0 10 Barki et al. (1993) 5 55 Summer (2000) 6 19 Longstaff et al.(2000) 7 32 Cule et al. (2000) 4 55 Kliem (2001) 4 38 Schmidt et al. (2001) 14 33 Houston et al. (2001) 0 29 Murti (2002) 0 12 Addision (2003) 10 28 Carney et al. (2003) 4 21
Sample of Boehm’s top 10 development risks [10]
17
Risk Risk Reduction Personnel shortfalls Staffing with top talent; job matching; teambuilding; training
& career development; early scheduling of key personnelUnrealistic time & cost estimates
Multiple estimation techniques; design to cost; incrementaldevelopment; recording and analysis of past projects;standardization of methods
Developing the wrong software functions
Improved software evaluation; formal specification methods;user surveys; prototyping; early user manuals
Developing the wrong user interface
Prototyping; task analysis; Developing the wrong user interface user involvement
Gold plating Requirements scrubbing; prototyping; cost-benefit analysis; design to cost
Late changes to requirements
Stringent change control procedures; high chance threshold; incremental development (deferring changes)
Development technically too difficult
Technical analysis; cost-benefit analysis; prototyping; staff training & development
2.1.2. Brainstorming
18
Project Stakeholders meet to identify the potential risks powered by by their extensive knowledge regarding the project and suggest the risk reduction solutions.
A popular approach for brainstorming is the facilitated workshop [4]. It is a workshop to identify the potential risks where its members are those with full-time engagements in the project with considerable responsibilities and covering critical technologies and commercial issues. Clients and suppliers should be aboard as well.
2.1.2. Brainstorming
19
This workshop is managed by a facilitator who ensures that everyone is participant, manage discussion threads and compile outputs into risk list. If the Project Manager has the facilitation skills then he could be a candidate, however, the workshop members may be steered as discussions could go toward certain direction in favor of the PM preferences. It is more convenient to have an independent person of the Project with much knowledge about the nature of such projects to be the facilitator.
2.1.3. Causal Mapping (1/4)
A causal map is a network diagram depicts causes and effects. Events are the (nodes) and causal relationships are the (links) between nodes representing causality or influence. Events affect each other through positive or negative causal relationship and effect [7]. In the example [5] blow the low staff turnover is a indication that we hire experienced staff (causality relation is positive). The more experienced staff are available, the higher productivity rate is developed (causality relation is positive). Consequently, the deadlines are met (causality relation is positive) and the management pressure tends to be low (causality relation is negative). On the other side, if we don’t have clear user requirements, that would cause running operations in unstable environment (causality relation is positive). Consequently, we hardly meet the deadline (causality relation is negative).
2.1.3. Causal Mapping (2/4)
22
Low staff turnover
Experienced Staff
High productivity
Uncertain user
requirements
Unstable
environment
Heavy Management
pressure
Deadlines met
+
+ -
+
+-
[5]
2.1.3. Causal Mapping (3/4)
23
The simple cause-risk-effect structure depicts the cause that drives a probability of having risk. Once this risk emerged, it will drive the impact of the effect. The impact of the effect is variable depending on the influence of the risk [6].
Cause
Risk
Effect
Drives probability
Drives Variable impact
simple cause-risk-effect structure
2.1.3. Causal Mapping (2/2)
24
A further modification of this structure is the Causal map showing cause–risk–effect multiple relationships - a more complex but more flexible approach to describing composite risks. It expands each element into a network of links, recognizing that cause–risk–effect relationships are usually not singular (1:1:1) but multiple (many : many : many) as shown in the figure behind [6].
This causal map can be useful in generating improved understanding of project risks. Based on maps, policies to reduce the likelihood of undesirable outcomes to the project could be developed [1].
Cause
Risk
Effect
Drives probability
Drives Variable impact
simple cause-risk-effect structure
Causal map of cause–risk–effect multiple relationships [6]
25Effect(s)
EffectEffect Effect
RiskRiskRisk
Cause Cause Cause
Cause
[6]
2.2. Risk Analysis (1/4)
27
To analyze risks, the probability of occurrence, impact and priority should be assessed for each risk.
The probability attribute is the possibility degree that risk could occurs. The probability value is between 0 (very low) and 1 (very high) estimated by subject-matter experts. (Probability Table) [2]
The impact attribute is the consequences or the damage of the risk. The impact value is between 1 (very low) and 5 (very high) assessed against four categories: Cost, Schedule, Scope, Performance [2]. (Impact table).
2.2. Risk Analysis (2/4)
28
Program/Project
Objective
Very Low Minor
Low Moderate
Medium Serious
High Critical
Very High Catastrophic
Cost Insignificant increase
Increase < 2% ofbudget baseline
Increase 2–5% ofbudget baseline
Increase 6–10% of budget baseline
Increase > 10% of budget baseline
Schedule Insignificant slippage
Slippage < 2% of project baseline schedule
Slippage 2–5% of project baseline schedule
Slippage 6–10% of project baseline schedule
Slippage > 10% of project baseline schedule
Scope Scope decrease barely noticeable
Minor areas of scope affected
Major areas of scope affected
Scope reduction unacceptable to sponsor
Project outcome is effectively useless
Performance
Performance degradation barely noticeable
Performance degradation noticeable, but does not fail acceptance criteria
Performance reduction requires sponsor approval
Performance reduction unacceptable to sponsor
Project outcome is effectively useless
Impact Table [2]
2.2. Risk Analysis (3/4)
29
Probability Description Probability of Occurrence
Very High (Extremely likely)
≥81% and =100%
High (Probable) 61% – 80% Medium (Possible) 41% – 60% Low (Unlikely) 21% – 40% Very Low >l% – ≤20%
Probability Table [2]
2.2. Risk Analysis (4/4)
30
To assess the priority of risk, Risk exposure (Risk Priority) is used. Risk Exposure is the result of multiplying the probability of a risk to occur by the impact of occurrence. Prioritizing risks enables project manager to determine the capacity in terms of time and resources needed to manage and monitor the risks.
Risk Exposure (Risk Priority) = Impact of Risk x Probability of Occurrence [2]
Two ways of calculating the impact of a risk, either by estimating the financial loss in term of cash or on scale of 1 (very low) to 5 (vey high) assessed against four categories: Cost, Schedule, Scope, Performance [2]. (Impact table) on the previous slide.
Estimating the impact value is difficult as it isn’t easy to predict the potential loss in the event of risk occurrence; it could be limited or dramatic. The same for the probability as it is difficult to have a unified opinion from various experts to estimate the probability of a risk to occur due to different backgrounds and experiences ; but we could take the average.
Risk Exposure (Calculation Method 1)
32
Potential damage in terms of financial loss. For example a severe earthquake causes a damage of £0.5 million.
Probability 0 (0% chance to happen) to 1 (100% sure of occurrence). For example: 0.01 means one in hundred chance. (check probability of occurrence table)
CRI = £0.5m x 0.01 = £5,000the amount needed for an insurance premium
Composite Risk Index values tend to be high at the inception of the project as the probability of expecting risks to occur is high. As soon as we approach finalizing the project, the values drop gradually as the possibility of having risks decrease.[1]
Risk Exposure (Risk Priority) = Impact of Risk x Probability of Occurrence
Risk Exposure (Calculation Method 2) [2]
33
Risk PrioritiesImpact
Very High
Probability of
occurrence
High
Medium
Low
Very Low
Very High High Medium Low Very low
Very LowPriority
LowPriority
MediumPriority
HighPriority
Very HighPriority
Risk Watch List
Monitor Monitor
Develop Mitigation
strategy
Monitor
Develop Contingency
strategy
Monitor
2.3. Risk Response
35
Risk response is the process of selecting the best possible response for each risk. Responses for negative risks [2, 14]:
1. Risk acceptance2. Risk avoidance3. Risk reduction4. Risk transfer5. Risk Escalation 6. Risk Mitigation
Responses for positive risks [13]:7. Exploit8. Share9. Enhance
2.3.1. Risks Acceptance
36
Risk acceptance is a response technique for unavoidable risks or risks we could deal with its impact and keep it in control. Besides the cost of mitigating this risk is accepted. There are two types of risk acceptance strategies: Passive and Active. Passive is about accepting risks that can’t be avoided where project team deal with such risk with no adequate response strategy. Whilst, the active is the same but the project team has a contingency plan to deal with the risk [9].
2.3.1. Risks Acceptance
37
Example of the risk acceptance: the risk of purchasing a defective CD of a ready-made software product. Replacing this copy would cause a delay of 5 days to a task having 25 days slack time. The Passive acceptance is used in this case as It does not worth exerting efforts to anticipate the problem and do something about it. It is simpler to wait and check if something goes wrong with the CD, then, we take corrective action [15].
2.3.2. Risks Avoidance
38
It is the opposite of risk acceptance. It is a response technique that avoids exposure to any risk. Risk Avoidance is the most expensive response as it might make changes to the project management plan to eliminate risks and mitigate their impacts [16,9].
Example of Risk avoidance: purchasing a ready made software product to avoid risks associated with the in-house development such as poor effort and time estimates, availability of resources, compatibility issues, etc.
2.3.3. Risks Reduction
39
Risk avoidance avoids exposure to any risk. Whilst Risk reduction reduces the likelihood and severity of a possible loss, in other words, it limits the exposure to risk by taking some actions. Risk reduction employs a bit of risk acceptance along with a bit of risk avoidance.
Example of risk limitation: A company accepts that a hard drive may fail and avoids a long period of failure by having backups [16].
Risk Reduction Leverage (RRL) is an index compares the exposure of a single event BEFORE and AFTER managing the risk. The higher the Leverage, the better the solution [17].
2.3.3. Risks Reduction
40
Consider the following example: the impact of having severe compatibility issue might add 10,000$ to expenses. The probability of having this risk is 30% before risk reduction and 10% after risk reduction. The cost of making updates to overcome the compatibility issue is 1000$ The Risk Reduction Leverage (RRL) = (0.3x 10,000) – (0.1x x 1000) / 1000 = (3000 - 1000) / 1000 = 2. If RRL > 1.00 then it worth doing the reduction otherwise the cost of the risk reduction activity outweighs the probable gain from implementing the action [1]
Risk Reduction Leverage (RRL) = Risk Exposure Before - Risk Exposure After
cost of risk reduction
2.3.4. Risk Transfer
42
Risk is outsourced to another entity. This is the case of companies outsourcing some of the their operations like cloud computing platforms, backup solutions, infrastructure management, customer service, payroll services, etc. Transferring such risks let entities focus on their core competencies [16,9].
2.3.5. Risk Mitigation
43
While risk reduction reduces the likelihood of a risk to occur, the risk mitigation is concerned with taking early actions to minimize the probability and/or impact of a risk when it occurs. It is far effective than trying to repair the damage after the occurrence of a risk [16,9].
Examples of Risk Mitigation: Adapting less complex processes, conducting more tests, or choosing a more stable suppliers [1].
2.3.6. Risk Escalation
44
Risk escalation is transferring the ownership and accountability of a risk to the senior management, whereas reporting, is about maintaining the ownership and accountability for that risk @ your level, but keep informing the senior management of the current situation and the way of handling [18].
2.3.6. Risk Escalation
45
The reasons to escalate a risk [18]:
1. The risk is above your target level of risk and there is nothing to do to reduce that to your target. Risk is escalated to the senior management that has the authority and the accountability to accept that risk on behalf of the organization.
2. When the treatments you need to do around that risk are outside of the delegation of the original risk. For example If the decision is taken not to spend the money on that, then, risk is going to be accepted at a higher level.
3. Shared risk with other organizational functions or with external entities where you can’t approach an agreement.
2.4. Risk Monitoring
47
Risk monitoring and updating is a process concerned with tracking the identified risks and make sure they are in control. It also keeps identifying any new risks that might popup across the project while managing the contingency plans in case they are needed. On top of that, this process collects and captures lessons learned during managing and mitigating risk for the upcoming risk assessments and efforts allocation. This process continues throughout the life of the project.
3. 3-point AON Estimation
The 3-point AON estimation has an advantage over the previously discussed AON mentioned in unit 4 for the following reasons [21]:• An increased accuracy estimation over the single
point estimates• Better commitment from project team members as
estimate considers risk in the assignment• Useful information on the risks of each task.
48
[20]
3. 3-point AON Estimation
To evaluate the impact of risk in AON (mentioned in unit 4), firstly, we create the network of activities. Secondly, we estimate the early and late start of tasks by applying forward and backward path. Thirdly, we calculate the total float time and identify the critical path. Fourthly, we calculate (Most Optimistic, Most pessimistic, Most likely) estimates for each activity and derive the expected task duration, besides calculating the standard Deviation and variance. Finally, we determine probability of meeting expected date
3. 3-point AON Estimation
The Expected Task Duration (TE) = (TO + TL x 4 + TP ) / 6 [20]Most Optimistic (TO) – the most optimistic estimate of the task durationMost Likely (TP) - the most pessimistic estimate of the task durationMost Pessimistic (TL) - = the most likely time
TE is an estimate from three estimates the team member assigned for their task. It reflects the amount of risk in the task and the severity of the impact of the optimistic and pessimistic risks.
Standard deviation (SD) is the average deviation from the estimated time = (TP-T0)/6 The higher SD the greater the amount of uncertainty
50
TO TL TE TP
t
Probability of finishing a task in time t
[20]
Task Name Normal Time (Days)
Crashed Time (Days)
Normal Cost ($)
Crashed Cost ($)
Mark Utilities
3 3 0 0
Dig Holes 2 1 100 200Buy Trees .5 .5 50 50Buy Flowers .5 .5 50 50Plant Trees 2 1 100 200Plant Flowers
1 .5 50 100
Buy Fence .5 .5 25 25Install Fence 1 .5 25 50
total 400 67551
This example below is about planting trees & flowers and installing a fence [22]. Shaded tasks are running concurrently.
3-point AON Estimation Example (1/4)
3-point AON Estimation Example (2/4)
52
0 3 31 Mark Utilities 0 3 3
3 2 52 Dig Holes
3 2 5
5 2 75 Plant Trees
5 2 7
7 1 86 Plant Flowers
7 1 8
8 1 98 Install Fence
8 1 9
3 0.5 3.53 Buy Trees
4.5 0.5 5
3 0.5 3.57 Buy Fence
7.5 0.5 8
3 0.5 3.54 Buy Flowers
6.5 0.5 7
ES Duration EFTask Name
LS Duration LF
3-point AON Estimation Example (3/4)
CRITICAL PATH TASKS (Longest Duration)TASK TO TL TP TE ES EF LS LF Slack SD V
1 1 3 5 3 0 3 0 3 0 .67 .4442 2 4 7 4.17 3 7.17 3 7.17 0 .83 .6945 1 3 6 3.17 7 10.17 7 10.17 0 .83 .6946 1 3 5 3 10 13 10 13 0 .67 .4448 1 2 4 2.17 13 15.17 13 15.17 0 .5 .254
TOTAL 7 15 27 15.51 3.5 2.530OTHER PROJECT TASKS tasks 3, 4 and 7 are concurrent and do not add to the timeline
TASK TO TL TP TE ES EF LS LF FLOAT SD V3 .5 1 3 1.25 0 1.25 3 4.25 3 .42 .174 .5 1 3 1.25 0 1.25 3 4.25 3 .42 .177 .5 1 3 1.25 1.25 2.50 4.25 5.50 3 .42 .17
TOTAL 1.5 3 9 3.75 1.26 .51
ES=Earliest Start EF= Earliest Finish LS=Latest Start LF=Latest Finish
• Slack time = ES – LS or EF – LF • Tasks with zero slack time are on the critical path
53
The expected task duration = TE = (To + TL x 4+ TP) / 6 Standard deviation = SD = (TP-T0)/6
variance = V = SD2
54
3-point AON Estimation Example (4/4)
• Set The target for completion is 15 days (T)• Calculate the z value using NORMSDIST in Excel = 37.66 which mean there is about a
37.66% chance of not meeting the target of 15 days.
Critical Path Tasks (longest duration)Task To TLTP TE ES EF LS LF SLACK SD V
Mark Utilities 1 3 5 =SUM(B3*1+C3*4+D3*1)/6 0 3 0 3 =I3-G3 =(D3-B3)/6 =K3*K3Dig holes 2 4 7 =SUM(B4*1+C4*4+D4*1)/6 3 7 3 7 =I4-G4 =(D4-B4)/6 =K4*K4Plant trees 1 3 6 =SUM(B5*1+C5*4+D5*1)/6 7 10.17 7 10.17=I5-G5 =(D5-B5)/6 =K5*K5Plant flowers 1 3 5 =SUM(B6*1+C6*4+D6*1)/610 13 10 13 =I6-G6 =(D6-B6)/6 =K6*K6Install edging 1 2 4 =SUM(B7*1+C7*4+D7*1)/61315.171315.17=I7-G7 =(D7-B7)/6 =K7*K7TOTAL =SUM(E3:E7) =SUM(L3:L7)
Enter desired time completion date: 15 Probability of completion: =NORMDIST(B10,E8,SQRT(L8),TRUE)
ES=Earliest Start EF= Earliest Finish LS=Latest Start LF=Latest Finish
Conclusion (1/2)
55
Risk is unplanned event causing adverse effect on the project course resulting in extending the completion time, amplifying costs and confusing schedules of resources. There are 3 major types of risks: Project, Technical and Business and could be positive and negative
Risk Management Framework stages include: Risk Identification, Risk Analysis, Risk Response ( Risk Acceptance / Avoidance / Transfer / Escalation / Mitigation) and Risk Monitor and Control
To identify risks, we used Checklists, Brainstorming or Causal mapping
To analyze risks, the probability of occurrence, impact and priority should be assessed for each risk.
To assess the priority of risk, Risk exposure (Risk Priority) is used. Risk Exposure is the result of multiplying the probability of a risk to occur by the impact of occurrence. Prioritizing risks enables project manager to determine the capacity in terms of time and resources needed to manage and monitor the risks.
Conclusion (2/2)
56
Risk response is the process of selecting the best possible response for each risk. Responses for negative risks:1.Risk acceptance2.Risk avoidance3.Risk reduction4.Risk transfer5.Risk Escalation6.Risk Mitigation
Responses for positive risks:1.Exploit2.Share3.Enhance
Risk monitoring and updating is a process concerned with tracking the identified risks and make sure they are in control.
The 3-point AON estimation has an advantage over the previously discussed AON for the following reasons: • An increased accuracy estimation over the single point estimates• Better commitment from project team members as estimate considers risk in the
assignment• Useful information on the risks of each task.
References
57
1. http://www.cdf.toronto.edu/~csc340h/winter/lectures/w5/L5-part1-6up.pdf2. Alfred (Al) Florence The MITRE Corporation: http://www.asq509.org/ht/a/GetDocumentAction/i/794263. http://sce.uhcl.edu/helm/Risk_Man_WEB/docs%5C46iSWcklist.pdf4. https://mushcado.wordpress.com/2011/01/11/using-brainstorming-techniques-to-identify-project-risk/5. http://www.slideshare.net/sweetyammu/spm-unit-36. https://www.apm.org.uk/sites/default/files/open/Prioritising%20Project%20Risks_.pdf7. http://www.it.bton.ac.uk/staff/gw4/papers/ECITE%202004%20paper.pdf8. IEEE Std 1540-2004, IEEE Standard for Software Life Cycle Processes— Risk Management; IEEE9. http://www.projectmanagementlexicon.com/topics/strategies-for-negative-risks-threats/10. http://users.humboldt.edu/smtuttle/f14cs458/458lect10-1/458lect10-1-boehm-top10-risks-to-post.pdf11. http://www.iaeng.org/publication/IMECS2011/IMECS2011_pp732-737.pdf12. http://www.projectmanagementlearning.com/what-is-the-difference-between-positive-and-negative-risks.html13. http://www.brighthubpm.com/risk-management/48400-how-to-respond-to-positive-risks/14. Software Project Management: By Bharat Bhushan Agarwal, Shivangi Dhall Sumit Prakash Tayal
https://books.google.com.eg/books?id=79Hq5WbyAzkC&pg=PA218&lpg=PA218&dq=risk+avoidance+examples+software+development&source=bl&ots=i5uxQaR66N&sig=YAbLVopbKFBDE8vZeUvSMM8C1g4&hl=en&sa=X&ved=0CBsQ6AEwADgKahUKEwjDv7z3zerGAhVLXRQKHT9pDMs#v=onepage&q=risk%20avoidance%20examples%20software%20development&f=false
15. http://pmtips.net/Blog/defining-risk-management-part-6-risk-response16. http://www.mha-it.com/2013/05/four-types-of-risk-mitigation/17. http://www.omsar.gov.lb/ICTGPG/Web/20.8_Risk_Reduction_Leverage_(RRL).htm18. https://www.paladinrisk.com.au/risk-escalation/19. http://punsarab.blogspot.com/2012/08/a-project-network-illustrates_30.html20. http://data.bolton.ac.uk/learningresources/projman/units/u06/u06.html21. http://4pm.com/3-point-estimating-2/22. http://libvolume6.xyz/mechanical/btech/semester7/operationsresearch/pertcpmtechniques/
pertcpmtechniquespresentation2.pdf
Tempus
Thank you for your attention.