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

Catastrophic Critical

1.1 5.3

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

Po

ten

tial

Im

pac

t

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.