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.