risk & risk management- madhavan karthikeyan

May-2013

1

agenda• myths about risk & risk management

• reactive vs proactive risk strategies

• why risk, what's a risk & risk management?

• origin

• risk and management concern

• exercise-20min

• risk management steps

• examples of risk & preventive measures

• metrics & information gathering technique

it is impossible to foresee, what can go wrong

in my project before it is begin?

i can only do so much; then whatever happens,

happens

i already have controls in place; why manage risk?

i am not risk management experts; why should we have to manage risk?

i have managed this project for several years, every situation is stored in my memory, no need for a separate mechanism to manage risk.

risk is a negative thought . i start a project with only positive thoughts in my mind. because i am a positive person u know...

there is no risk in my project because i perform all the work. i don’t delegate most of the work.

myths about risk & risk management

reactive risk strategy

is also called as “Indiana Jones school of risk management”

Jones when faced with difficulty would say

“don’t worry i will think of something”

never worrying about problems until they

happened

Jones would react in some heroic way

proactive risk strategy

is begin long before technical work is initiated

potential risks are identified, assessed, ranked by importance for managing risk

primary objective is to avoid risk, but not all risks can be avoided

hence the team works to control the risk probability and impact

reactive vs proactive risk strategies

5

why risk?Wright brothers

to improve at anything, we must at some point push ourselves outside our

comfort zone

business or personal growth is impossible without taking a risk

a risk is an un-certainty / potential problem

It may occur

It may not occur

a risk management is proactively managing un-certainty /

potential problem

what’s a risk & risk management ?

not reactive

origin7

risk manage

ment

time management

disaster management

diversification

urgent important

not-urgent not-important

fire fightingcost, delay, quality

delegation

obsolete product

mitigation preparation

recovery response

infrastructure

man power

minimum fund

ROI

risk and management concern

8

Y

XZ

(impact / damage)

(probability)(management concern)

extreme

almost certain high

negligible

2nd priority

1st priority

risk management steps9

step 1• risk

identification

step 2• risk

quantification

step 3• risk response

step 4• risk

monitoring & control

fighter jet is extremely risky, yet well managed

quantificationY

XZ

(impact / damage)

(probability)(management concern)

extreme

almost certainhigh

zone-1

zone-2

zone-4

zone-3

zone-5 negligible

2nd priority

1st priority

quantification(customized to scale 5)

Probability Description

5Almost certain

> 75%

No strategy or current strategy will resolve this issue, Alternatives will be required, mitigation actions urgently to be done.

4Likely

> 40% - 75%Current strategy will probably not resolve this issue. Alternatives will be required, mitigation actions needed.

3Moderate

> 20 to 40%Current strategy may not resolve this issue. Alternatives may be required, mitigation actions are to be considered.

2Unlikely

> 5 to 20%Current strategy should resolve this issue.

1Rare

5% or lessCurrent actions are in order. Issue can be resolved quickly and easily.

Impact Description

5 Extreme Unacceptable, operational failure

4 Major Loss of operational capability

3 Moderate Remedial action required

2 Minor Limited operational impact

1 Insignificant Minimal operational impact

Risk Rating Colour Coding

High ≥ 12

Medium to High ≥ 9 - < 12

Medium ≥ 5 - <9

Low to Medium ≥ 2 - < 5

Low ≥ 0 - < 2

Risk Rating =Probability * Impact

response

avoid

• if you can prevent it from happening, it definitely won’t hurt your project

transfer

• pay someone else to accept it for you. the most common way to do this is to buy insurance

mitigate

• taking some sort of action that will cause it to do as little damage to your project as possible

accept

• when you can’t avoid, mitigate, or transfer a risk, then you have to accept it. but even when you accept a risk, at least you’ve looked at the alternatives and you know what will happen if it occurs

the process of putting into action of all the risk planning done earlier in the project life-cycle.

monitor identified risks

identify new risks

ensure the proper execution of planned risk responses

evaluate the overall effectiveness of the risk management plan in

reducing risk

PD & QA team members and stakeholders should be alert in looking for risk symptoms, as well as for new project risks.

monitoring & control

examples of risk & preventive measures

risk factor preventive measureshuman error on part of PD, QA engineer

employ the best engineer; rewards; training; peer reviews; team formation; adopt process; use of checklist; Error pattern analysis of individual PD, QA engineer

VSX URQ & Deve Ticket does not match completely

win-win URQ agreement between product manager, PD & QA; high fidelity prototyping; SRS spec in early phase

user interfaces do not fit needs high fidelity prototyping; development of scenarios; description of users

constant alteration of VSX URQ incremental development; change management process; change control board

problem with PMO / product manager

audits, team formation

examples of risk & preventive measures

risk factor preventive measuresdelays in critical path time buffer in critical path. most

experienced engineer for these tasks. alternative scheduling. explore possible earlier delivery of components

task complexity early feedback

planning taking up too much time, not enough time to work on product

don’t get more detailed than necessary with the planning

dependency key development is floating for long duration

dependency on one key engineer should be removed by delegation and empowerment

effort in risk management activities

# of new risks

# of previously identified risks

metrics

the most important technique in identifying risks is information-gathering techniques

information –gathering techniques

SWOT analysis

brainstorming

interviews

root cause identification

documentation reviews + audit repost + customer feedback

assumptions analysis

diagramming techniques

Questionnaire Guide in the identification of risks: SEI CMMI

Requirements a:Stability Are requirements changing even as the product is being produced?

b. Completeness Are requirements missing or incompletely specified?

c. Clarity Are the requirements unclear or in need of interpretation?

d. Validity Will the requirements lead to the product the customer has in mind?

e. Feasibility Are there requirements that are technically difficult to implement?

f. Precedent Do requirements specify something never done before or beyond the experience of program personnel?

g. Scale Is the system size or complexity a concern

appendix

appendixQuestionnaire Guide in the identification of risks: SEI CMMI

Requirements a. Functionality Are there any potential problems in designing to meet functional requirements?

b. Difficulty Will the design and/or implementation be difficult to achieve?

c. Interfaces Are internal interfaces (hardware and software) well defined and controlled?

d. Performances Are there stringent response time or throughput requirements?

e. Testability Is the product difficult or impossible to test?

appendixQuestionnaire Guide in the identification of risks: SEI CMMI

Code and Unit Test

a. Feasibility Is the implementation of the design difficult or impossible?

b. Unit Testing Is the specified level and time for unit testing adequate?

c. Coding/Implementation Are the design specifications in sufficient detail to write code: Will the design be changing while coding is being done?

appendixQuestionnaire Guide in the identification of risks: SEI CMMIIntegration and Test

a. Environment Is the integration and test environment adequate? Are there problems developing realistic scenarios and test data to demonstrate any requirements?

b. Product Is the interface definition inadequate, facilities inadequate, time insufficient? Are there requirements that will be difficult to test?

c. System Has adequate time been allocated for system integration and test? Is system integration uncoordinated?

Are interface definitions or test facilities inadequate

Development Environment

a. methods

b procedures, and

c. tools in the production of the software products

“he who doesn't risk never gets to drink champagne"

-Russian Proverb

take away quote

Contact: madhavan5002@gmail.com