Software Engineering Project
Management SE603
Unit 6: Risk Management
Egypt, 15.6.2015
Tempus
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.
2
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)
3
Unit 6: List of topics
1. Risk Types
2. Risk Management Framework
2.1. Risk Identification
2.1.1. Checklists
2.1.2. Brainstorming
2.1.3. Causal Mapping
2.2. Risk Analysis
2.3. Risk Response
2.3.1. Risks Acceptance
2.3.2. Risks Avoidance
2.3.3. Risks Reduction
2.3.4. Risk Transfer
2.3.5 Risk Mitigation
2.3.6. Risk Escalation
2.4. Risk Monitoring
3. 3-point AON Estimation
4
Risk Management
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]
Step 0 Initiation
Step 1: Defining Scope
and Objectives
Step 2: Understanding
Client infrastructure
Step 3 Project
Characteristics
Analysis
review
Lower level
detail
Step 4 Identifying
deliverables
Step 5 Effort
Estimation
For Each
activity
Step 6 Handling risks
Step 10 Low-Level
Planning
Step 7 Resources
Allocation
Step 9 Plans
Execution
Step 8 Plans Review
5
1. Risk Types (1/3)
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
Definitio
n
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.
6
1. Risk Types (2/3)
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.
7
1. Risk Types (3/3)
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]
8
2. Risk Management Framework
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
9
Risk Management Flow
Enter
Reject
Risk
No
Risk management
continues by new
owners of the risk
Identify
Risk
Yes
Conduct Risk
Analysis
Transfer No
Escalate
No
Yes
Accept
Risk
Conseq
uences
No
Risk
Still
Valid
Yes
Mitigat
ion
No Strateg
ies
Requir
ed
Has Risk
been
mitigate
d
Yes
No
Has
risk
occur
red
Execute Mitigation
Strategies
Develop
Contingency
Strategies
Yes
Reject Risk
When risks occur they
become issues and are
managed as issues
Yes
No
Yes
Close Risk
Due to
continuous
monitoring
is the risk
still valid?
Transfer or
Escalate
Initial
Accepta
nce
Is Risk
Valid
Close Risk
Continue Risk
Management
Develop
Mitigation
Strategies
Go to issue
Management
Yes
Yes
Do
contingenc
y strategies
exist
No
Continge
ncy
strategi
es
require
d
Yes
No
Continuous Monitor and control Risk
Alfred (Al) Florence The MITRE Corporation [2]
2.1. Risk Identification
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
11
2.1.1. Checklists
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.
12
2.1.1. Checklists
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].
13
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?
Example of
Have software requirements been clearly delineated/allocated?
Software
Have the system-level software requirements been reviewed, inspected
with system engineers, hardware engineers, and the users to insure clarity Engineering
and completeness?
Institute (SEI)
Is an impact analysis conducted for all changes to baseline requirements?
Software Risk
Software Planning Phase
Checklist –
Have the end user requirements been represented in the concept phase?
Are roles and responsibilities for software clearly defined and followed? Taxonomy
Is the level of expertise for software language, lifecycle, development
(1/2) [3]
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?
14
System Requirements Phase
RISK
Yes/No
Accept/
Work
Is the software management plan being followed? Any
updates needed?
Example of
Are standards and guidelines sufficient to produce clear design
Software
and code?
Engineering
Will there be a major loss of personnel (or loss of critical
personnel)?
Institute (SEI)
Is there a need to create simulators to test software?
Software Risk
Software Implementation Phase
Checklist –
Is there auto-generated code?
Taxonomy
Are implementation personnel familiar with the development
(2/2) [3]
environment, language, and tools?
Is the software management plan still being used? Is it up-todate?
Are there coding standards?
Is the schedule being maintained? Have impacts been
accounted for (technical, resources, etc.)? Is it still reasonable?
15
Software Project Risks [11]
AUTHOR(YEAR)
DIMENSION OF RISKS
NUMBER OF
SOFTWARE RISKS
McFarlan (1981)
Boehm (1991)
Barki et al. (1993)
3
0
5
54
10
55
Summer (2000)
Longstaff et al.(2000)
6
7
19
32
Cule et al. (2000)
Kliem (2001)
4
4
55
38
Schmidt et al. (2001)
Houston et al. (2001)
Murti (2002)
14
0
0
33
29
12
Addision (2003)
Carney et al. (2003)
10
4
28
21
16
Sample of Boehm’s top 10 development risks [10]
Risk
Risk Reduction
Personnel shortfalls
Staffing with top talent; job matching; teambuilding; training
& career development; early scheduling of key personnel
Unrealistic time & cost
estimates
Multiple estimation techniques; design to cost; incremental
development; 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 Technical analysis; cost-benefit analysis; prototyping; staff training
too difficult
& development
17
2.1.2. Brainstorming
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.
18
2.1.2. Brainstorming
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.
19
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)
Low staff
turnover
[5]
Uncertain
user
requirements
High
productivity
+ Experien +
ced Staff
+
Unstab
le
environ
ment
+
-
Deadline
s met
-
Heavy
Management
pressure
22
2.1.3. Causal Mapping (3/4)
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
Drives probability
Risk
Drives
Variable impact
Effect
simple cause-risk-effect structure
23
2.1.3. Causal Mapping (2/2)
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
Drives probability
Risk
Drives
Variable impact
Effect
simple cause-risk-effect structure
24
Causal map of cause–risk–effect multiple
relationships [6]
Cause
Cause
Cause
Cause
Risk
Risk
Risk
Effect
Effect
Effect
Effect(s)
[6]
25
2.2. Risk Analysis (1/4)
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 subjectmatter 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).
27
Impact Table [2]
2.2. Risk Analysis (2/4)
Program/Pr
oject
Objective
Very Low
Minor
Low
Moderate
Medium
Serious
High
Critical
Very High
Catastrophic
Cost
Insignificant Increase < 2% of
increase
budget baseline
Increase 2–5% of
budget baseline
Increase 6–10%
of budget
baseline
Increase >
10% of
budget
baseline
Schedule
Insignificant Slippage < 2% of
slippage
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
Performanc
e
Performanc
e
degradation
barely
noticeable
Performance
Performance
degradation
reduction requires
noticeable, but
sponsor approval
does not fail
acceptance criteria
Performance
reduction
unacceptable to
sponsor
Project
outcome is
effectively
useless
28
2.2. Risk Analysis (3/4)
Probability Table [2]
Probability Description Probability of
Occurrence
Very High (Extremely
≥81% and =100%
likely)
High (Probable)
61% – 80%
Medium (Possible)
41% – 60%
Low (Unlikely)
21% – 40%
Very Low
>l% – ≤20%
29
2.2. Risk Analysis (4/4)
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
30
experiences ; but we could take the average.
Risk Exposure (Calculation Method 1)
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
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,000
the amount needed for an
insurance premium
32
Risk Exposure (Calculation Method 2) [2]
Risk Priorities
Very High
High
Medium
Low
Very Low
Very High
High
Medium
Low
Very low
Very Low
Priority
Low
Priority
Medium
Priority
High
Priority
Very High
Priority
Risk Watch
List
Monitor
Monitor
Monitor
Monitor
Develop
Mitigation
strategy
Develop
Contingency
strategy
33
2.3. Risk Response
Risk response is the process of selecting the best possible
response for each risk. Responses for negative risks [2, 14]:
1.
2.
3.
4.
5.
6.
Risk acceptance
Risk avoidance
Risk reduction
Risk transfer
Risk Escalation
Risk Mitigation
Responses for positive risks [13]:
1. Exploit
2. Share
3. Enhance
35
2.3.1. Risks Acceptance
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].
36
2.3.1. Risks Acceptance
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].
37
2.3.2. Risks Avoidance
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 inhouse development such as poor effort and time
estimates, availability of resources, compatibility
issues, etc.
38
2.3.3. Risks Reduction
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].
39
2.3.3. Risks Reduction
Risk Reduction Leverage (RRL)
= Risk Exposure Before - Risk Exposure After
cost of risk reduction
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]
40
2.3.4. Risk Transfer
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].
42
2.3.5. Risk Mitigation
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].
43
2.3.6. Risk Escalation
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].
44
2.3.6. Risk Escalation
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.
45
2.4. Risk Monitoring
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.
47
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
[20]
• Useful information on the risks of each task.
48
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
Probability of
finishing a
task in time t
[20]
t
TO
TL TE
TP
The Expected Task Duration (TE) = (TO + TL x 4 + TP ) / 6 [20]
Most Optimistic (TO) – the most optimistic estimate of the task duration
Most Likely (TP) - the most pessimistic estimate of the task duration
Most 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
3-point AON Estimation Example (1/4)
Task Name
This example below is
about planting trees &
flowers and installing a
fence [22]. Shaded tasks
are running
concurrently.
Normal Time
(Days)
Crashed Time
(Days)
Normal Cost
($)
Crashed
Cost ($)
Mark
Utilities
3
3
0
0
Dig Holes
2
1
100
200
Buy Trees
.5
.5
50
50
Buy Flowers
.5
.5
50
50
Plant Trees
2
1
100
200
Plant
Flowers
1
.5
50
100
Buy Fence
.5
.5
25
25
Install Fence
1
.5
25
50
400
675
total
51
3-point AON Estimation Example (2/4)
3
0.5
3.5
7 Buy Fence
7.5
0.5
8
ES
3
0.5
3.5
3
3
0.5
5
3
2
5
1 Mark Utilities
0
3
3
LS
4.5
5
2 Dig Holes
2
7
5 Plant Trees
3
2
5
3
0.5
3.5
EF
Task Name
3 Buy Trees
0
Duration
5
2
7
Duration
1
8
6 Plant Flowers
7
7
1
8
LF
8
1
9
8 Install Fence
8
1
9
4 Buy Flowers
6.5
0.5
7
52
3-point AON Estimation Example (3/4)
variance = V = SD2
• Slack time = ES – LS or EF – LF
• Tasks with zero slack time are on the critical path
The expected task duration = TE = (To + TL x 4+ TP) / 6
TASK
1
2
5
6
8
TOTAL
TASK
3
4
7
TOTAL
Standard deviation = SD = (TP-T0)/6
CRITICAL PATH TASKS (Longest Duration)
TO
TL
TP
TE
ES
EF
LS
LF
Slack
SD
1
3
5
3
0
3
0
3
0
.67
2
4
7
4.17
3
7.17
3
7.17
0
.83
1
3
6
3.17
7
10.17
7
10.17
0
.83
1
3
5
3
10
13
10
13
0
.67
1
2
4
2.17
13
15.17
13
15.17
0
.5
7
15
27 15.51
3.5
OTHER PROJECT TASKS tasks 3, 4 and 7 are concurrent and do not add to the timeline
TO
TL
TP
TE
ES
EF
LS
LF
FLOAT
SD
.5
1
3
1.25
0
1.25
3
4.25
3
.42
.5
1
3
1.25
0
1.25
3
4.25
3
.42
.5
1
3
1.25
1.25
2.50 4.25 5.50
3
.42
1.5
3
9
3.75
1.26
ES=Earliest Start EF= Earliest Finish
LS=Latest Start
LF=Latest Finish
V
.444
.694
.694
.444
.254
2.530
V
.17
.17
.17
.51
53
3-point AON Estimation Example (4/4)
Task
To TL TP
Mark Utilities
1 3 5
Dig holes
2 4 7
Plant trees
1 3 6
Plant flowers
1 3 5
Install edging
1 2 4
TOTAL
Critical Path Tasks (longest duration)
TE
ES EF LS LF SLACK
=SUM(B3*1+C3*4+D3*1)/
6
0 3 0 3 =I3-G3
=SUM(B4*1+C4*4+D4*1)/
6
3 7 3 7 =I4-G4
=SUM(B5*1+C5*4+D5*1)/
6
7 10.17 7 10.17=I5-G5
=SUM(B6*1+C6*4+D6*1)/ 1
1
6
0 13 0 13 =I6-G6
=SUM(B7*1+C7*4+D7*1)/ 1
1
6
3 15.17 3 15.17=I7-G7
SD
V
=(D3-B3)/6
=K3*K3
=(D4-B4)/6
=K4*K4
=(D5-B5)/6
=K5*K5
=(D6-B6)/6
=K6*K6
=(D7-B7)/6
=K7*K7
=SUM(L3:L7
)
=SUM(E3:E7)
1
Enter desired time completion date: 5
•
•
Probability of completion:
=NORMDIST(B10,E8,SQRT(L8),TRUE)
Set The target for completion is 15 days (T)
Calculate the ES=Earliest
z value using
NORMSDIST
in Excel
= 37.66
mean
there is about a
Start EF=
Earliest Finish
LS=Latest
Start which
LF=Latest
Finish
37.66% chance of not meeting the target of 15 days.
54
Conclusion (1/2)
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.
55
Conclusion (2/2)
Risk response is the process of selecting the best possible response for each risk.
Responses for negative risks:
1.Risk acceptance
2.Risk avoidance
3.Risk reduction
4.Risk transfer
5.Risk Escalation
6.Risk Mitigation
Responses for positive risks:
1.Exploit
2.Share
3.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.
56
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
http://www.cdf.toronto.edu/~csc340h/winter/lectures/w5/L5-part1-6up.pdf
Alfred (Al) Florence The MITRE Corporation: http://www.asq509.org/ht/a/GetDocumentAction/i/79426
http://sce.uhcl.edu/helm/Risk_Man_WEB/docs%5C46iSWcklist.pdf
https://mushcado.wordpress.com/2011/01/11/using-brainstorming-techniques-to-identify-project-risk/
http://www.slideshare.net/sweetyammu/spm-unit-3
https://www.apm.org.uk/sites/default/files/open/Prioritising%20Project%20Risks_.pdf
http://www.it.bton.ac.uk/staff/gw4/papers/ECITE%202004%20paper.pdf
IEEE Std 1540-2004, IEEE Standard for Software Life Cycle Processes— Risk Management; IEEE
http://www.projectmanagementlexicon.com/topics/strategies-for-negative-risks-threats/
http://users.humboldt.edu/smtuttle/f14cs458/458lect10-1/458lect10-1-boehm-top10-risks-to-post.pdf
http://www.iaeng.org/publication/IMECS2011/IMECS2011_pp732-737.pdf
http://www.projectmanagementlearning.com/what-is-the-difference-between-positive-and-negative-risks.html
http://www.brighthubpm.com/risk-management/48400-how-to-respond-to-positive-risks/
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&ve
d=0CBsQ6AEwADgKahUKEwjDv7z3zerGAhVLXRQKHT9pDMs#v=onepage&q=risk%20avoidance%20examples%2
0software%20development&f=false
http://pmtips.net/Blog/defining-risk-management-part-6-risk-response
http://www.mha-it.com/2013/05/four-types-of-risk-mitigation/
http://www.omsar.gov.lb/ICTGPG/Web/20.8_Risk_Reduction_Leverage_(RRL).htm
https://www.paladinrisk.com.au/risk-escalation/
http://punsarab.blogspot.com/2012/08/a-project-network-illustrates_30.html
http://data.bolton.ac.uk/learningresources/projman/units/u06/u06.html
http://4pm.com/3-point-estimating-2/
http://libvolume6.xyz/mechanical/btech/semester7/operationsresearch/pertcpmtechniques/pertcpmtech
niquespresentation2.pdf
57
Thank you for
your attention.
Tempus