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: [email protected]