Software Project Management: ResearchColab- Risk Management (Document-7) Presented in 4th year of Bachelor of Science in Software Engineering (BSSE) course at Institute of Information Technology, University of Dhaka (IIT, DU).

1. i
ResearchColab
Risk Management
Team: Reckless 7
Institute of Information Technology
University of Dhaka
25th November, 2016

2. 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. 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. 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. 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. 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. 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. 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. 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. 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.