Risk Management Plan: A Practitioner Approach

- Pradeep K Dash (praddash@in.ibm.com)

SECTION: I
Risk Overview
Risk Management
Risk Identification
Initial Risk Catalog:
Risk Analysis & Categorization
Mitigating Risks
Identifying Risks for an AMS Account
SECTION: II
Risk Management with IBM Program Work Center (IPWC)
IPWC Interface for Risk Management
IPWC Customizing Risk Log
Risk Probability and Impact would decide Risk Level
IPWC - Create Risk
IPWC Risk Closure
IPWC Reopening a Risk
IPWC Associating a Risk with Task
IPWC Associating a Risk with Discussion
IPWC Association in Risk Log
APPENDIX: I
Risk Management with IBM Rational Portfolio Manager
APPENDIX: II
References

SECTION: I

Risk Overview

What is Risk?
A Risk is a potential problem or situation, if
materializes, may adversely affect the Project. When
risks materialize they are no longer risks but
Problems.
All Projects have risks and all risks are ultimately
handled,
Category I: Some Risks never happen or disappear from the
scenario
Category II: Some Risks develop into problems and those demand
attention.
Category III: A few escalate into crisis and destroy the Project
4

SEI Definition of Risk

For a risk to be understandable, it must be
expressed clearly. Such a statement must
include,
a description of the current conditions that
may lead to the loss
a description of the loss

Risk Example
A company has introduced object-oriented (OO) technology into its
organization by selecting a well-defined project "X" with hard schedule
constraints to pilot the use of the technology. Although many "X" project
personnel were familiar with the OO concept, it had not been part of their
development process, and they have had very little experience and
training in the technology's application. It is taking project personnel
longer than expected to climb the learning curve. Some personnel are
concerned, for example, that the modules implemented to date might be
too inefficient to satisfy project "X" performance requirements.
The risk is: Given the lack of OO technology experience and training,
there is a possibility that the product will not meet performance or
functionality requirements within the defined schedule.
Reference: http://www.sei.cmu.edu/risk/
6

What causes risks to fall into third category?

In initial stages, software projects are not estimated and
planned with acceptable accuracy. We need to compromise in
different aspects like client pressure, resource availability and
finance.
Software project status reporting is often wrong and
misleading. It is hardly we get the exact picture of the
development status of a software project.
Software quality and reliability is sometimes unacceptably
poor.
There are many other factors which also causes Risks to be
destructive.
7

Risk Management
Risk management ensures that risks never fall into
third category, i.e. restricts risks in taking shape of
crisis which leads to project closure.
Steps of Risk Management:
Risk Identification
Risk Analysis & Categorization
Risk Mitigation

Risk Identification: What can possibly go wrong??

Risk listing is an iterative process.
To begin with we have to prepare a risk catalog.
In process of development life cycle, some risks will
never happen, some will be developed and handled
and some new risk will arise and will be added to the
list.
So at initial stage of software development a risk
catalog may include following risks,

Initial Risk Catalog:

Staff Risk

Key staffs will not available when needed

Key skill sets will not available when needed
Staff will leave the project in halfway

Equipment Risk

Required equipment will not be available in time

Access to hardware & network will be restricted
Equipment will fail

Client Risk

Client resources will not made available as required

Client staffs will delay decision
Deliverables will not be reviewed as per schedule
Experienced client staffs will be replaced with less qualified
and experienced staffs

Scope Risks

Requirement of additional effort may arise

Changes of scope may deemed to be included in the
project
Scope of project changes will be introduced without the
knowledge of Project Management team

10

Initial Risk Catalog:

Technology
Risks

The technology will have performance and technical

limitations that endanger the project
Technology components will not be easily integrated
The Technology is new and poorly understood

Delivery Risks

System response time will not be adequate

System capacity requirement will exceed available capacity
The system will fail to meet functional requirements

Physical Risks

The office may be damaged by fire, flood or other calamities

A computer virus may affect the entire system
The confidential materials may be stolen

11

Risk Analysis & Categorization

Out of different ways of risk categorization the simplest
way is to categorize risks as Extreme (4), High (3),
Medium (2) and Low (1).
The categorization and Degree of Risk depends upon
two factors,
The probability of occurrence
Impact on project if it occurs.
The Probability and Impact are categorized as High (3),
Medium (2) and Low (1) themselves, and their
relationship or combination decides the degree of Risk.
12

Risk Analysis & Categorization:

Probability

Impact

Degree of Risk

High

High

Extreme

High

Medium

High

High

Low

Medium

Medium

High

High

Medium

Medium

Medium

Medium

Low

Low

Low

High

Medium

Low

Medium

Low

Low

Low

Low
13

Risk Analysis & Categorization:

Assessment and Aligning Actions an example
Criteria of
assessing impact as
High or Medium or
Low may vary from
project to project
considering project
cost, volume,
stakeholders
priority, SLA etc.
Actions and
Probability criteria
can be adjusted as
required.

14

Risk Analysis & Categorization

Specific to IBM, Impacts are rated against Impact on
Cost, Schedule and Quality.
Total Impact is sum of Impact on Cost, Schedule and
Quality.
Exposure is (Probability + Total Impact)/2.It combines
Probability and Total Impact into a single value.

15

Mitigating Risks
To mitigate a risk we need to reduce its probability,
impact or both. So we need to be proactive to reduce
the probability and impact of Risks.
Risk identification and prioritization activities are only
useful if actions are defined and executed to mitigate
risks.
Aggressive, proactive risk mitigation actions for top
priority risks are essential to achieve the benefits of
Software Risk Management.
Risk mitigation actions are defined individually for
project risks.
16

Mitigating Risks
Risks may be categorized according to SDLC like
Requirement Risks, Design Risks, Coding Risks and
Testing Risks etc.
In some cases, immediate action will be called for; in
others, future consideration will be more appropriate.
So for each and every risk we need to prepare an action
plan and have to strictly implement the defined plan.
Risk, its analysis, action or mitigation plan as well as the
implementation details should be well documented.
It is a simplistic way of Risk Management.
17

Identifying Risks for an AMS Account

Risks (Maintenance Projects)

Probability
(H/M/L)

Impact
(H/M/L)

Status

Maintenance Projects General

1. Has the organization been adequately involved in the
construction and other stages?
2. Is there an adequately long phase planned where the
organization's maintenance team works with the existing
maintenance team?
3. Have there been too many emergency fixes in the past?
4. Does the code follow standards?
5. Has the system been developed in bits and pieces?
6. Has the system been maintained in a formal manner till now?
7. Is the source code for maintenance / Re-engineering are
commented adequately?
8. Has a configuration management tool been identified?
18

Identifying Risks for an AMS Account

Risks (Maintenance Projects)

Probability
(H/M/L)

Impact
(H/M/L)

Status

Maintenance Projects Requirement Analysis

1. Have interview schedules been violated in the past?
2. Is there adequate commitment from the top and middle level
management for the project?
3. Are there adequate numbers of client personnel in the team?
4. Is the client's organization rapidly undergoing a change?
5. Has the system boundary been clearly defined?
6. Is the documentation of existing systems and procedures
adequate?
7. Are there adequate numbers of team members involved from
the client organization?
8. Is the methodology employed well known in your
organization?
19

Identifying Risks for an AMS Account

Risks (Maintenance Projects)

Probability
(H/M/L)

Impact
(H/M/L)

Status

Maintenance Projects Requirement Analysis

9. Is the business area rapidly undergoing a change?
10. Are the requirements, contract obligations, contract
schedules, changes to requirements not documented?
11. Are requirements, contract obligations, contract schedules
are unclear, incomplete or not signed-off by customer
12. Are requirements are incomplete, unclear or not
understood by the organization, and will need to be refined or
defined by your organization during this project with no
opportunity to re-price?
13. Will requirements be refined, defined or validated during a
requirement phase or due diligence phase with an opportunity
to re-price the design and implementation phase?
20

Identifying Risks for an AMS Account

Risks (Maintenance Projects)

Probability
(H/M/L)

Impact
(H/M/L)

Status

Maintenance Projects Requirement Analysis

14. Does the requirements does not match the solution
proposed?
15. Has performance / availability criteria been defined for the
project?
16. Are the performance / availability requirements stringent
(above the organization's standard commitments)?
17. Are the performance / availability requirements not clearly
defined?
18. Can performance / availability requirements be met with
high degree of certainty? (for example, the solution has not
been previously implemented or validated)
19. Is the solution baseline or services baseline not well defined
or bounded?
21

Identifying Risks for an AMS Account

Risks (Maintenance Projects)

Probability
(H/M/L)

Impact
(H/M/L)

Status

Maintenance Projects Requirement Analysis

20. Are there any requirements that are technically difficult to
implement?
21. Are there any state-of-art requirements?
22. Is the code very complex?
Maintenance Projects Testing
1. Are regression test packs available?
2. Is there adequate knowledge of the tools that are being
used?
3. Are there some team members who were a part of the earlier
stages?

22

Identifying Risks for an AMS Account

Risks (Maintenance Projects)

Probability
(H/M/L)

Impact
(H/M/L)

Status

Maintenance Projects Testing

4. Has the coding been done to standards?
5. Is the software to be tested been developed by multiple
vendors?
Maintenance Projects Acceptance and Implementation
1. Has the completion criteria been clearly defined?
2. Does the team contain some of the members of the teams of
the previous stages?
3. Is the documentation adequate?
4. Has the testing in regression test been formal and
documented?
5. Others (Please specify the risk)
23

SECTION: II

Risk Management with

IBM Program Work Center (IPWC)

24

IPWC Interface for Risk Management

View Shows the Risks that are logged .The details

like the Title , Status, Owner, Probability, Impact
and Level are listed.
View can be modified To be discussed later
25

IPWC Customizing Risk Log

Click the Select

View Columns
26

Risk Probability and Impact would decide Risk Level

When the Probability and the Impact are changed,

the Level will get updated appropriately
27

IPWC - Create Risk

Delete Risk

Create Risk

Select the Is Calculated check box if you want the Risk Level to be auto-calculated
If the Is Calculated is unchecked , each of the parameters can be selected and set appropriately.
The Consequence / Mitigation Strategy and the status needs to be updated appropriately.
When the risk is created/deleted/updated IPWC will send the notification to the stakeholders
identified with escalation matrix.
28

IPWC Risk Closure

Click on the Close

button to close the risk

To close the
risk-view or
page. Nothing to
do with risk
closure

After the Risk is closed the Reopen Option will be activated it is useful in case the Risk
needs to be reopened.
Certain fields such as Closed By, Date will be auto-updated when you press the close
button.
29

IPWC Reopening a Risk

Click on the Reopen button
to Reopen the risk

Assign Risk to a resource

A closed risk can be reopened in case needed in future.

This feature is useful considering during a project life cycle same risk may prop
up more than once such as staffing/attrition related, release timeline etc.

30

IPWC Associating a Risk with Task

Click to create a task

You can create associated task(s) for a risk it is useful

to track the action items identified for risk mitigation.
31

IPWC Associating a Risk with Discussion

Associate with a
discussion

Attachments docs,
MoM, Mitigation sign
ups, action item
approvals etc.

Similarly you can associate a risk with related discussion.

Also the interface provides services to attach the
documents related to a risk such as related MoM, detailed
mitigation plan, related approvals etc.

32

IPWC Association in Risk Log

The view shows that the Risk

is associated with a Task and
Discussion
33

34

Thank You!!

35