Professional Documents
Culture Documents
Risks, Opportunities, Issues - Management and Analysis Form
Risks, Opportunities, Issues - Management and Analysis Form
Analysis Form
Project Name: PEG Project risks - pooled as Learning/Reference
PQAL: NA
Version History
[This section should provide a history of changes to the document. Keep the latest version on the top]
Date Version Update Author Reviewer
19-Sep-18 1.0 As per latest LV MK
tempalte
14-Mar-19 2.0 1. Added Risks of AK AD
New Projects
2. Updated Risk
Status of existing
database
CG
CG
GR
4 Easily_Det 1 16 Shraddha
ectable Kulkarni
has joined
and having
KT from
LMS
Somewhat 4 Somewhat 4 112 Pull Not-Occur
_likely _Detectabl another
e resource
with the
same skills
from ISG
Team
4 Easily_Det 1 12 Rekha
ectable Navle to
continue in
LMS
Support
who will
replace
Shonali
4 Easily_Det 1 16
ectable
4 Easily_Det 3 48 Dhiraj to
ectable coninue in
LMS
Support till
Richa is
back
4 Easily_Det 1 16 Make
ectable existing
resources
work extra
Hours to
cover loss
of
resources
when team
size
reduces to
2
Risk Management - Guidelines
1 Risk Risk No. Risk Reference number - Use serial numbering [optionally, concatenate Project Name/Code with
2 Identification Date of Risk Identification Date of Risk Identification
3 Process Area / Phase / Functional A Category can be used in Validation sheet
Note: Use areas like - Domain,Technology, Integration, Delivery,
Disposal, Processes used (any new processes, procedures,
methods, etc), Products used (any new free-ware/open source, etc),
Contract Risks, Business (Budget/Costs , Schedule), Resource /
Infrasturcture, Performance Risks, Skills, Deployment and Support,
Environment
e.g. Phases of Software development - Design , Process Area of
BPO - Transition, Pilot, Execution, etc.
4 Process Requirement E.g. Design should meet the customer requirement - technology requirement
5 Mode of Failure Give only 2 or 3 words to state this. E.g. Non-identical Environment
[what may go wrong with the what may go wrong with the Requirement -E.g. Technology not met
6 Requirement]
Risk Description Give detailed description of the mode of failure, from perspective of affected party
[detailed description of the mode
of failure, from perspective of
affected party]
7 Impact Impact description Give detailed description of the impact
8 Impact On [what Parameter- For each Parameter like Schedule, Efforts (cost), Quality, etc. a separate line of Risk Analysi
9 Schedule
Impacted /Party
Effort (Cost) / Quality, etc.] List L0003 of dCORUM to be referred. Also available in Validation sheet here
10 Severity [S] Refer table below
11 [S] Range is even numbers - Validation based on the values in previous cell
12 Cause Cause of Mode of Failure The cause is to be documented which will lead to further analysis
13 Risk Source [Internal, Vendor, Customer]
[Internal, Vendor, Customer]
14 Occurrence Refer table below
[O]
[Probability of the occurrence of the
cause]
BackRisk
to topAnalysis • In all cases, irrespective of the final
RPN, all Severity scores greater than
8 has to be treated as a high priority
risk.
• In case of a tie between RPNs,
preference will go to the higher
severity, followed by Occurrence and
then detection
e.g: If the RPN score is low but the
severity may be high and therefore,
you need to prioritize it higher.
Risk_Assessme RPN
nt
Catastrophic >500
Critical 300 - 500
Marginal 100 - 299
Negligible <100
Pr
oje
ct
De
tail
s
lly, concatenate Project Name/Code with Serial number]
chnology requirement
s in previous cell
. Analyse the top 3.If there are more than 1, then evaluate on the highest Severity, then Occurrence, then Detection
Back to top
Occurrence Meaning probability
Description 1,2,3 Not very likely < 20%
Loss of one or more primary functionalities, 9,10 Almost always > 80%
Significant erosion of Project Margin
-Product inoperative;
-Customer may pull out;
-Loss / Bleeding;
Detection
10
9
8
7
6
5
4
3
2
1
Risk Identification
Back to top
Detection Meaning Description
1,2,3 Easily Detectable Can be easily caught during review / test