i
ResearchColab
Risk Management
Team: Reckless 7
Institute of Information Technology
University of Dhaka
25th November, 2016
Contents
1.1 Introduction.....................................................................................................3
1.2 Project Risk Management...............................................................................3
1.3 Risk Identification...........................................................................................3
Risk Category................................................................................................4
Schedule........................................................................................................4
Requirement Risk..........................................................................................4
Project Management Risk.............................................................................4
Product/Technology Risk..............................................................................4
Customer Risk...............................................................................................4
Human Resources & Contractors Risk .........................................................5
1.4 Risk Register...................................................................................................5
1.5 Heat Map.........................................................................................................8
1.6 Evaluating Risks .............................................................................................9
1.7 Monitoring and Review ..................................................................................9
1.8 Conclusion ....................................................................................................10
3
1.1 Introduction
Risk is inevitable in a business organization when undertaking projects. However, the project
manager needs to ensure that risks are kept to a minimal. Risks can be mainly divided
between two types, negative impact risk and positive impact risk.
Not all the time would project managers be facing negative impact risks as there are positive
impact risks too. Once the risk has been identified, project managers need to come up with a
mitigation plan or any other solution to counter attack the risk.
1.2 Project Risk Management
Managers can plan their strategy based on four steps of risk management which prevails in an
organization. Following are the steps to manage risks effectively in an organization:
 Risk Identification
 Risk Quantification
 Risk Response
 Risk Monitoring and Control
1.3 Risk Identification
Managers face many difficulties when it comes to identifying and naming the risks that occur
when undertaking projects. These risks could be resolved through structured or unstructured
brainstorming or strategies. It's important to understand that risks pertaining to the project can
only be handled by the project manager and other stakeholders of the project.
Risks, such as operational or business risks will be handled by the relevant teams. The risks
that often impact a project are supplier risk, resource risk and budget risk. Supplier risk
would refer to risks that can occur in case the supplier is not meeting the timeline to supply
the resources required.
The common Project Risk List Reference below which are divided into a number of risk
categories are samples of potential risks of a project may be exposed to and should only be
used by the Project Team as a reference and starting point for risk identification during the
project risk management planning.
The category of risks identification is listed below-
4
Risk Category Risks
Schedule 1. Schedule not realistic, only "best case".
2. Important task missing from the schedule.
3. A delay in one task causes cascading delays in
dependent tasks.
4. Unfamiliar areas of the product take more time than
expected to design and implement
Requirement Risk 1. Requirements have been base lined but continue to
change.
2. Requirements are poorly defined, and further definition
expands the scope of the project
3. Specified areas of the product are more time-consuming
than expected.
4. Requirements are only partly known at project start
5. The total features requested may be beyond what the
development team can deliver in the time available.
Project
Management Risk
1. PM has little authority in the organization structure and
little personal power to influence decision-making and
resources
2. Priorities change on existing program
3. Project key success criteria not clearly defined to verify
the successful completion of each project phase.
4. Projects within the program often need the same
resources at the same time
5. Date is being totally driven by need to meet marketing
demo, trade show, or other mandate; little consideration
of project team estimates
Product/Technology
Risk
1. Development of the wrong user interface results in
redesign and implementation.
2. Development of extra software functions that are not
required (gold plating) extends the schedule.
3. Requirements for interfacing with other systems are not
under the team’s scope.
4. Dependency on a technology that is still under
development lengthens the schedule.
5. Selected technology is a poor match to the problem or
customer
Customer Risk 1. Customer insists on new requirements.
2. Customer review/decision cycles for plans, prototypes,
and specifications are slower than expected.
3. Customer insists on technical decisions that lengthen the
5
schedule.
4. Customer will not accept the software as delivered even
though it meets all specifications.
5. Customer has expectations for development speed that
developers cannot meet.
Human Resources
& Contractors Risk
1. Critical development work is being performed by one
developer
2. Some developers may leave the project before it is
finished.
3. Hiring process takes longer than expected.
4. Personnel need extra time to learn unfamiliar software
tools, hardware and programming language.
5. Contract personnel leave before project is complete.
6. Conflicts among team members result in poor
communication, poor designs, interface errors and extra
rework.
7. Personnel with critical skills needed for the project
cannot be found.
8. Contractor does not deliver components when promised.
1.4 Risk Register
A risk register or risk log is a scatter plot used as risk management tool and to fulfill
regulatory compliance acting as a repository for all risks identified and includes additional
information about each risk, e.g. nature of the risk, reference and owner, mitigation measures.
Severity and likelihood of the project will be scaled in the following ways-
Categorized Harm
Severity
Severity Level Risk
Normal 1 Very Low
Negligible 2 Low
Marginal 3 Moderate
Critical 4 High
Catastrophic 5 Extreme
Where,
 Catastrophic – Multiple Deaths
 Critical – One Death or Multiple Severe Injuries
 Marginal – One Severe Injury or Multiple Minor Injuries
 Negligible – One Minor Injury
 Normal - Less Than Injury
6
Likelihood Category Likelihood Level
Less Likely 1
Likely 2
Very Likely 3
A table of Risk Register is given below-
Potenti
al Risk
Dimen
sion
Ref
.
No
Risk
Scope
(Inter
nal/E
xtern
al)
Attribut
es
Description Sever
ity
Like
liho
od
Risk Plan Priorit
y
Status
Requ
ireme
nts
1.1 Exte
rnal
Maintai
nability
Continually
changing
requirements
5 3 Add effort
on
requirement
analysis
with
collaboratio
n.
High Closed
1.2 Inter
nal
Plannin
g
System
requirement
not
adequately
identified
4 2 Give a
dummy
project view
at first.
High Closed
1.3 Exte
rnal
Plannin
g
Unclear
system
requirements
5 2 More
meeting
required
with
stockholders
High Closed
1.4 Inter
nal
Depend
encies
Project
involves the
use of new
technology
3 1 Required
experts or
train
existing tem
members
Medi
um
Closed
Team 2.1 Inter
nal
Depend
encies
Inexperience
team
members
4 1 Assign
experienced
project
manager
Medi
um
Closed
2.2 Inter
nal
Depend
encies
Inadequately
trained
development
team
members
3 2 More
meeting
required
with
stockholders
High Closed
2.3 Inter
nal
Depend
encies
Team
members
lack
of
specialized
skill required
5 1 Continuous
meeting and
monitoring
High Closed
7
by the
project
User 3.1 Exte
rnal
Maintai
nability
Users
resistance to
change
3 2 Consult
with User
and project
team
Medi
um
Closed
3.2 Exte
rnal
Maintai
nability
Users with
negative
attitudes
toward the
project
3 1 Consult
with User
and project
team
Medi
um
Closed
3.3 Exte
rnal
Maintai
nability
Conflicts
between
users
4 1 Consult
with User
and project
team
High Closed
Proje
ct
comp
lexity
Plann
ing &
Cont
rol
4.1 Inter
nal
Resour
ces
Lack of
effective
project
management
technology
4 2 Project
planning
should be
done
keeping in
mind about
existing
tools and
technology
Medi
um
Closed
4.2 Inter
nal
Monito
ring
Project
progress not
monitored
closely
enough
5 1 Project
managemen
t and team
collaboratio
n should be
increased
Medi
um
Closed
4.3 Inter
nal
Plannin
g
Inadequate
estimation of
required
resources
3 2 Backup
equipment
should be
ready
Low Closed
4.4 Inter
nal
Plannin
g
Poor project
planning
5 1 Assign
experienced
project
manage
Medi
um
Closed
Orga
nizati
onal
Envir
onme
nt
5.1 Inter
nal
Maintai
nability
Change in
organizationa
l
management
during the
project
4 1 Consult
with User
and project
team
Medi
um
Closed
8
5.2 Exte
rnal
Depend
encies
Corporate
politics with
negative
effect on the
project
2 2 Continuous
meeting and
monitoring
Low Open
5.3 Inter
nal
Monito
ring
Unstable
Internal
Communicati
on
environment
3 3 Signed off
the
agreement
with
detailed.
Medi
um
Closed
1.5 Heat Map
Visualization is a powerful tool for simple information risk analysis. The simple of act of
placing risks in special relationship to each other allows a quick overview of essential
elements of your risk profile. As importantly, it allows you to communicate that simple risk
profile to others that aren’t as versed in information security, IT, and information
management. A popular risk visualization tool is an information risk heat map. The heat map
for our project is given below-
Figure1.5: Heat Map
CatastrophicCritical
1.15.3
5.2 1.32.2, 3.1, 4.3 1.2, 4.1
2.3, 4.2,
5.1, 5.2
1.4, 3.2 2.1, 3.3
High
Medium
Low
Normal Negligible Marginal
PotentialImpact
Probability
9
1.6 Evaluating Risks
The risk evaluation step involves deciding whether the identified risk is acceptable,
after considering:-
 The controls already in place
 The cost impact of managing the risks or leaving them untreated
 Benefits and opportunities presented by the risk
 The risks borne by other stakeholders
During this process, the risk rating identified during the analysis step, is compared against all
other risks and assigned priority for each risk.
1.7 Monitoring and Review
Regular monitoring and review of risks is an important part of the ResearchColab program. It
ensures that new risks are; detected; added to the Risk Register, managed and that action
plans are implemented and progressed effectively. The key to the monitoring process is to
establish a cost, schedule, and performance management indicator system over the entire
program that the PM uses to evaluate the status of the program. The indicator system should
be designed to provide early warning of potential problems to allow management actions.
Risk monitoring is not a problem-solving technique, but rather, a proactive technique to
observe the results of risk handling and identify new risks.
Test and Evaluation (T&E), Earned Value (EV), Technical Performance Measurement,
Program Metrics & Schedule Performance Monitoring are Some monitoring techniques
which can be adapted to become part of a risk indicator system.
Risk mitigation strategies and specific action plans should be incorporated in the project
execution plan, or risk analyses are just so much wallpaper. Risk mitigations was planned and
has been executed according to given below-
 Characterized the root causes of risks that had been identified and quantified in
earlier phases of the risk management process.
 Evaluated risk interactions and common causes.
 Identified alternative mitigation strategies, methods, and tools for each major
risk.
 Assessed and prioritized mitigation alternatives.
 Selected and committed the resources required for specific risk mitigation
alternatives.
 Communicated planning results to all project participants for implementation.
10
Although risk mitigation plans developed in detail and executed by project manager
and team members, the project management developed standards for a consistent risk
mitigation planning process. Risk mitigation planning was continued beyond the end
of the “ResearchColab” project by capturing data and lessons learned that can benefit
for our future projects.
1.8 Conclusion
In fine it can be added that, software risk management, risks classification in this project, are
clearly described. If risk management process is in place for each and every software
development process then future problems could be minimized or completely eradicated.
Hence, understanding various factors under risk management process and focusing on risk
management strategies explained above could help in building risk free products in future.
Risk management is an on-going process, and is a combination of proactive management
directed activities within a program that are intended to accommodate the possibility of
failures. So, it should be controlled in standard way.

Software Project Management: Risk Management

  • 1.
    i ResearchColab Risk Management Team: Reckless7 Institute of Information Technology University of Dhaka 25th November, 2016
  • 2.
    Contents 1.1 Introduction.....................................................................................................3 1.2 ProjectRisk Management...............................................................................3 1.3 Risk Identification...........................................................................................3 Risk Category................................................................................................4 Schedule........................................................................................................4 Requirement Risk..........................................................................................4 Project Management Risk.............................................................................4 Product/Technology Risk..............................................................................4 Customer Risk...............................................................................................4 Human Resources & Contractors Risk .........................................................5 1.4 Risk Register...................................................................................................5 1.5 Heat Map.........................................................................................................8 1.6 Evaluating Risks .............................................................................................9 1.7 Monitoring and Review ..................................................................................9 1.8 Conclusion ....................................................................................................10
  • 3.
    3 1.1 Introduction Risk isinevitable in a business organization when undertaking projects. However, the project manager needs to ensure that risks are kept to a minimal. Risks can be mainly divided between two types, negative impact risk and positive impact risk. Not all the time would project managers be facing negative impact risks as there are positive impact risks too. Once the risk has been identified, project managers need to come up with a mitigation plan or any other solution to counter attack the risk. 1.2 Project Risk Management Managers can plan their strategy based on four steps of risk management which prevails in an organization. Following are the steps to manage risks effectively in an organization:  Risk Identification  Risk Quantification  Risk Response  Risk Monitoring and Control 1.3 Risk Identification Managers face many difficulties when it comes to identifying and naming the risks that occur when undertaking projects. These risks could be resolved through structured or unstructured brainstorming or strategies. It's important to understand that risks pertaining to the project can only be handled by the project manager and other stakeholders of the project. Risks, such as operational or business risks will be handled by the relevant teams. The risks that often impact a project are supplier risk, resource risk and budget risk. Supplier risk would refer to risks that can occur in case the supplier is not meeting the timeline to supply the resources required. The common Project Risk List Reference below which are divided into a number of risk categories are samples of potential risks of a project may be exposed to and should only be used by the Project Team as a reference and starting point for risk identification during the project risk management planning. The category of risks identification is listed below-
  • 4.
    4 Risk Category Risks Schedule1. Schedule not realistic, only "best case". 2. Important task missing from the schedule. 3. A delay in one task causes cascading delays in dependent tasks. 4. Unfamiliar areas of the product take more time than expected to design and implement Requirement Risk 1. Requirements have been base lined but continue to change. 2. Requirements are poorly defined, and further definition expands the scope of the project 3. Specified areas of the product are more time-consuming than expected. 4. Requirements are only partly known at project start 5. The total features requested may be beyond what the development team can deliver in the time available. Project Management Risk 1. PM has little authority in the organization structure and little personal power to influence decision-making and resources 2. Priorities change on existing program 3. Project key success criteria not clearly defined to verify the successful completion of each project phase. 4. Projects within the program often need the same resources at the same time 5. Date is being totally driven by need to meet marketing demo, trade show, or other mandate; little consideration of project team estimates Product/Technology Risk 1. Development of the wrong user interface results in redesign and implementation. 2. Development of extra software functions that are not required (gold plating) extends the schedule. 3. Requirements for interfacing with other systems are not under the team’s scope. 4. Dependency on a technology that is still under development lengthens the schedule. 5. Selected technology is a poor match to the problem or customer Customer Risk 1. Customer insists on new requirements. 2. Customer review/decision cycles for plans, prototypes, and specifications are slower than expected. 3. Customer insists on technical decisions that lengthen the
  • 5.
    5 schedule. 4. Customer willnot accept the software as delivered even though it meets all specifications. 5. Customer has expectations for development speed that developers cannot meet. Human Resources & Contractors Risk 1. Critical development work is being performed by one developer 2. Some developers may leave the project before it is finished. 3. Hiring process takes longer than expected. 4. Personnel need extra time to learn unfamiliar software tools, hardware and programming language. 5. Contract personnel leave before project is complete. 6. Conflicts among team members result in poor communication, poor designs, interface errors and extra rework. 7. Personnel with critical skills needed for the project cannot be found. 8. Contractor does not deliver components when promised. 1.4 Risk Register A risk register or risk log is a scatter plot used as risk management tool and to fulfill regulatory compliance acting as a repository for all risks identified and includes additional information about each risk, e.g. nature of the risk, reference and owner, mitigation measures. Severity and likelihood of the project will be scaled in the following ways- Categorized Harm Severity Severity Level Risk Normal 1 Very Low Negligible 2 Low Marginal 3 Moderate Critical 4 High Catastrophic 5 Extreme Where,  Catastrophic – Multiple Deaths  Critical – One Death or Multiple Severe Injuries  Marginal – One Severe Injury or Multiple Minor Injuries  Negligible – One Minor Injury  Normal - Less Than Injury
  • 6.
    6 Likelihood Category LikelihoodLevel Less Likely 1 Likely 2 Very Likely 3 A table of Risk Register is given below- Potenti al Risk Dimen sion Ref . No Risk Scope (Inter nal/E xtern al) Attribut es Description Sever ity Like liho od Risk Plan Priorit y Status Requ ireme nts 1.1 Exte rnal Maintai nability Continually changing requirements 5 3 Add effort on requirement analysis with collaboratio n. High Closed 1.2 Inter nal Plannin g System requirement not adequately identified 4 2 Give a dummy project view at first. High Closed 1.3 Exte rnal Plannin g Unclear system requirements 5 2 More meeting required with stockholders High Closed 1.4 Inter nal Depend encies Project involves the use of new technology 3 1 Required experts or train existing tem members Medi um Closed Team 2.1 Inter nal Depend encies Inexperience team members 4 1 Assign experienced project manager Medi um Closed 2.2 Inter nal Depend encies Inadequately trained development team members 3 2 More meeting required with stockholders High Closed 2.3 Inter nal Depend encies Team members lack of specialized skill required 5 1 Continuous meeting and monitoring High Closed
  • 7.
    7 by the project User 3.1Exte rnal Maintai nability Users resistance to change 3 2 Consult with User and project team Medi um Closed 3.2 Exte rnal Maintai nability Users with negative attitudes toward the project 3 1 Consult with User and project team Medi um Closed 3.3 Exte rnal Maintai nability Conflicts between users 4 1 Consult with User and project team High Closed Proje ct comp lexity Plann ing & Cont rol 4.1 Inter nal Resour ces Lack of effective project management technology 4 2 Project planning should be done keeping in mind about existing tools and technology Medi um Closed 4.2 Inter nal Monito ring Project progress not monitored closely enough 5 1 Project managemen t and team collaboratio n should be increased Medi um Closed 4.3 Inter nal Plannin g Inadequate estimation of required resources 3 2 Backup equipment should be ready Low Closed 4.4 Inter nal Plannin g Poor project planning 5 1 Assign experienced project manage Medi um Closed Orga nizati onal Envir onme nt 5.1 Inter nal Maintai nability Change in organizationa l management during the project 4 1 Consult with User and project team Medi um Closed
  • 8.
    8 5.2 Exte rnal Depend encies Corporate politics with negative effecton the project 2 2 Continuous meeting and monitoring Low Open 5.3 Inter nal Monito ring Unstable Internal Communicati on environment 3 3 Signed off the agreement with detailed. Medi um Closed 1.5 Heat Map Visualization is a powerful tool for simple information risk analysis. The simple of act of placing risks in special relationship to each other allows a quick overview of essential elements of your risk profile. As importantly, it allows you to communicate that simple risk profile to others that aren’t as versed in information security, IT, and information management. A popular risk visualization tool is an information risk heat map. The heat map for our project is given below- Figure1.5: Heat Map CatastrophicCritical 1.15.3 5.2 1.32.2, 3.1, 4.3 1.2, 4.1 2.3, 4.2, 5.1, 5.2 1.4, 3.2 2.1, 3.3 High Medium Low Normal Negligible Marginal PotentialImpact Probability
  • 9.
    9 1.6 Evaluating Risks Therisk evaluation step involves deciding whether the identified risk is acceptable, after considering:-  The controls already in place  The cost impact of managing the risks or leaving them untreated  Benefits and opportunities presented by the risk  The risks borne by other stakeholders During this process, the risk rating identified during the analysis step, is compared against all other risks and assigned priority for each risk. 1.7 Monitoring and Review Regular monitoring and review of risks is an important part of the ResearchColab program. It ensures that new risks are; detected; added to the Risk Register, managed and that action plans are implemented and progressed effectively. The key to the monitoring process is to establish a cost, schedule, and performance management indicator system over the entire program that the PM uses to evaluate the status of the program. The indicator system should be designed to provide early warning of potential problems to allow management actions. Risk monitoring is not a problem-solving technique, but rather, a proactive technique to observe the results of risk handling and identify new risks. Test and Evaluation (T&E), Earned Value (EV), Technical Performance Measurement, Program Metrics & Schedule Performance Monitoring are Some monitoring techniques which can be adapted to become part of a risk indicator system. Risk mitigation strategies and specific action plans should be incorporated in the project execution plan, or risk analyses are just so much wallpaper. Risk mitigations was planned and has been executed according to given below-  Characterized the root causes of risks that had been identified and quantified in earlier phases of the risk management process.  Evaluated risk interactions and common causes.  Identified alternative mitigation strategies, methods, and tools for each major risk.  Assessed and prioritized mitigation alternatives.  Selected and committed the resources required for specific risk mitigation alternatives.  Communicated planning results to all project participants for implementation.
  • 10.
    10 Although risk mitigationplans developed in detail and executed by project manager and team members, the project management developed standards for a consistent risk mitigation planning process. Risk mitigation planning was continued beyond the end of the “ResearchColab” project by capturing data and lessons learned that can benefit for our future projects. 1.8 Conclusion In fine it can be added that, software risk management, risks classification in this project, are clearly described. If risk management process is in place for each and every software development process then future problems could be minimized or completely eradicated. Hence, understanding various factors under risk management process and focusing on risk management strategies explained above could help in building risk free products in future. Risk management is an on-going process, and is a combination of proactive management directed activities within a program that are intended to accommodate the possibility of failures. So, it should be controlled in standard way.