Case study riskmanagementinpractice-v3

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/281097655
Risk Management in Practice: Process and Tools
Research · August 2015
CITATIONS
0
READS
6,518
1 author:
Some of the authors of this publication are also working on these related projects:
Statistics Tools View project
Philosophy, Psychology, Mysticism View project
Sreekumar Parameswaran Pillai
National Institute of Technology Calicut
9 PUBLICATIONS 0 CITATIONS
SEE PROFILE
All content following this page was uploaded by Sreekumar Parameswaran Pillai on 19 August 2015.
The user has requested enhancement of the downloaded file.

Risk
Management
in Practice
July 27
2009
Risk Management is one among the most critical functions in
Management.  Due to the intangible nature of the work involved,
pro‐active handling of risks becomes very crucial in software
projects.  The impact of many of the risks is seldom visible initially
and would surface in an unprecedented form towards the end of
the life cycle.  By then, it becomes too late for corrective steps and
the project runs into chaos.  This being one of the main reasons
for project failures, risk management deserves a special attention.
More than an exposition of theoretical discussions on the
different Risk management models, this paper focuses on the
process followed in the XXXXX[7] account and practical
implementation of the risk management process through features
available in Innotas, a commercial PPM [Program Project
management tool].
This case study takes one through the risk management functions
from process to process implementation sequentially.

Risk
Management
in Practice:
Process and
Tools
Sreekumar Parameswaran Pillai

2 | P a g e
© 2009, Sreekumar Parameswaran Pillai

Abstract
Risk Management is one among the most critical functions in Management.  Due to the intangible
nature of the work involved, pro‐active handling of risks becomes very crucial in software projects.
The impact of many of the risks is seldom visible initially and would surface in an unprecedented
form towards the end of the life cycle.  By then, it becomes too late for corrective steps and the
project runs into chaos.  This being one of the main reasons for project failures, risk management
deserves a special attention.

More than an exposition of theoretical discussions on the different Risk management models, this
paper focuses on the process followed in the XXXXX[7] account and practical implementation of the
risk management process through features available in SynergyOne, the organizational Project
management tool.  The objective of this paper is to research the possibility of using the entire set of
risk data in a project to derive futurist metrics. Based on analysis of the risk data captured during the
past one year in operation, a few simple but powerful metrics as project health indicators are also
discussed.  These are discussed as lead indicators on the health status of the project to the Project
Management Office (PMO) or the senior management.

This case study takes one through risk management functions from process to process
implementation sequentially.

What is risk?
What is risk?   ITIL defines risk as a measure of the exposure to which an organization may be
subjected. “This is a combination of the likelihood of a business disruption occurring and the
possible loss that may result from such business disruption. “

Risk Management
The Project Management Body of Knowledge defines risk management as “A subset of project
management that includes the processes concerned with identifying, analyzing, and responding to
project risk.  It consists of risk identification, risk quantification, risk response development and risk
response control.”  The risk in a project can be either due to external or internal causes.
“Risk management, in a business context, is about reducing the cost of risk, which includes the cost
of managing risk. No business is risk‐free, and risk management won’t eliminate all risks. Risk
management is about 3 R’s: returns, risks, and ruin.”
Risk management is about understanding the internal and external project influences that can cause
project failure. Once the project plan is built, a risk analysis should be performed on it. The result of
the initial risk analysis is a risk plan that should be reviewed regularly and adjusted accordingly. The
main purpose of risk management is to identify and handle the uncommon causes of project
variation. This is captured in a formal process in which risk factors are systematically identified,
assessed, and provided for.

3 | P a g e
Risk Management is the most important management function in any project irrespective of
whether this deals with civil construction, a hydro‐electric project or a space endeavor.  However
the one differentiator that delineates risks in the software industry would be that many of them are
intangible.   The risks also lives along with all other things in the virtual world and evade
management in the beginning, usually go unaddressed and get a hearing only when they start
retarding the progress or completely ruin the project.

Risk Management Process
The Risk Management followed in XXXXX[7] Account closely follows the Boehm’s Project Risk Model
as illustrated in figure 1.

Figure1. Boehm’s Project Risk Model

Most risk‐analysis process descriptions emphasize identification, ranking, and mitigation as
continuous processes and not just a onetime activity to be completed in the initial stages of
development alone.  So, all the steps in the illustration above are steps followed routinely, in an
iterative fashion throughout the life cycle of the project.

Risk
Management
Risk Assessment
Risk
Identification
Risk Analysis
Risk
Prioritization
Risk Control
Risk
Management
Planning
Risk Resolution
Risk Monitoring

4 | P a g e

Risk Identification
Risk identification is a concentrated effort to identify potential risks in the project.  Brainstorming
the team is one way to identify risks.  Other sources include organization database, risk trackers
from earlier projects etc.

The Project Owner is the key stakeholder in all the stages of risk management.  Identifying,
mitigating and resolving risks along with monitoring and closing them are very important functions
that the Project Manager handles on a continuum.

At the same time, even an experienced PM is seldom equipped to identify the entire set of potential
risks in a project.  A majority of risks, especially technical, design and architecture risks will be visible
to the development team much before it catches the PM’s attention.  Team members handling
specific functions will be in a better position to identify risks related to their areas.  For instance, an
architect will be in a better position to identify technological risk and those related to the
architecture.  A designer may be better poised to identify risks related to design.  This does not in
any way mean that these are the only people equipped to do it:  the entire team members can
contribute in a big way to identify risks and issues in the project.  The PM should be capable to
leverage the individual insights to identify the risks and make sure that they are tracked to closure.

The success of the manager depends on tapping this potential source of identification early in the
life cycle to help him initiate proactive steps in managing the project.  To facilitate this, an open
culture needs to be inculcated in the team where team members can freely voice the risks that they
foresee.  They should not be treated as problem creators but as sources of essential information.
The team should be encouraged to voice all potential conflicts up front.  Members who bring up
concerns should be encouraged and not penalized.

To this extent, the best strategy to adopt should be to isolate the mitigation from the reporter.
Mitigation plans sought from the reporter, would definitely hinder his coming forward a second
time, though each and every person should be trained to identify mitigation strategies. The PM can
also put the risks for a brainstorming during one of the meetings to identify potential mitigations if
required.

Risk Analysis
The Project Manager is the primary stakeholder in analyzing the risks in the project.  He facilitates
identification of all the potential risks and takes a direct interest in its analysis, mitigation and
resolution.
During the analysis phase, the PM rates the criticality of risks against the following variables:

1. Budgetary Impact
2. Schedule Impact

5 | P a g e
3. Customer Impact
4. Complexity
5. Type of risk – the area or the classification for this risk

At the end of this phase, the Project Manager comes up with a mitigation plan to each of the risks
identified in the project.  Mitigation can be sought from the team within, from external experts.  If
the risk is something that is out of his scope, he can definitely pass it to the responsible person in
the organization.  However, at no stages of the process does the ownership of this activity stray
away from the project manager.  He needs to track and close this risk to ensure that his project is on
track.

Risk Prioritization
After the risks have been identified and analyzed, their relative potential for occurrence and impact
on the project must be determined. This risk prioritization allows the project team to focus on those
critical few risks that will have the greatest potential for causing project failure.

This is done to rank the risks based on the probability of occurrence and the impact to the business.
Table 1 facilitates the project manager to identify the criticality of risks.

The four parameters:  Budget Impact, Schedule Impact and Customer impact and Complexity has
equal weight when it comes to classifying a risk on criticality.  A significant impact in any of these
parameters would term the risk as critical to the engagement.  The complexity of a risk is also
considered along the same axis.  In effect, a complex technical risk can become critical even though
it may not have a direct impact to the budget, schedule or the relationship; to highlight the
attention required to solve it.

Risk Control
Risk control consists of risk management planning, risk resolution and risk monitoring. As with risk
assessment, these three components are supported by sets of tools and techniques.

Once the mitigation is identified, the PM works towards the resolution of the risk.  If this is within his
scope of control, he will resolve the risk with appropriate actions.  If the resolution can be achieved
only by someone external to the team, he needs to transfer this risk to the responsible person and
follow it up to closure.

Risk control also requires that there is accountability on a person to resolve the risk within the target
time period before it impacts the project.  This ensures that risks do not go unaddressed.

6 | P a g e
Figure 2 illustrates the risk management steps followed in XXXXX[7] Account and the people
accountable at each step.

Figure2. Risk Management Process and Key Players in XXXXX[7]

7 | P a g e
Process Implementation:
Tools
Risk management tools help us in the following:
 Identifying risks
 Ensuring a mitigation plan
 Ownership
 Proper tracking and closure
 Escalations, Identifying impacts and highlighting critical risks
 Contribution to the risk database of the organization
There are a number of Risk Management tools available in the market.  A few of them specifically
for risk/issue tracking; whereas a few others offer this as an added feature along with its core
functionality. For instance, Bugzilla, a defect management tool facilitates tracking of risks/issues
while the core workflow is meant for defect management.
In USTGlobal, we have implemented tools that are very effective and efficient to dispatch this
function.  We can use the feature available in Kubera or SynergyOne; although the latter provides
this functionality more efficiently since this is a project management tool designed for the purpose.
The account utilizes SynergyOne work flow since this suits the process implemented.  Being a web‐
application, the tool facilitates implementing the same work flow in the distributed teams across the
globe.  The responsibilities of the individual roles and the permissions are set in accordance with the
established process.  This is already illustrated in Figure2.

Risk Identification
All the members in the project have access to this feature.  After logging into their respective
project, a team member can raise a risk from the “Issues” tab.  Web‐based risk management tools
have the advantage of facilitating collecting risks from multiple locations, especially in a distributed
environment where team members are not co‐located.

“The project team identified risks within its area of responsibility, appraises probabilities and
impacts, prioritizes risks, identifies preventive and precautionary measures, reports on the status or
risks, evaluates the efficiency of the preventive and precautionary measures and implements, if
necessary, the precautionary measures.
The risk manager supports the project team in the risk‐planning and risk‐control processes,
implements the risk‐management plan, organizes and administrates risk‐status reports, evaluates
new risks, checks the effectiveness of current risk plans and of the implementation of precautionary
measures.”i

Permission for this feature is enabled for all the team members since Risk Identification is an aspect
that each member in the team is a part of.  Team members are encouraged to log any risk that they
deem can affect the project execution.  While identifying a risk, the originator is welcome to log a

8 | P a g e
mitigation strategy as well.  However, this is not mandated since risk mitigation is more of a
management function; besides, insisting on a mitigation strategy may inhibit the technical team
members from pointing out the risk.

The members in the project can log issues in SynergyOne by going to the issues tab in their log in.
By clicking new, a new issue screen pops up where they can enter the risk/issue that they have
identified.  The only other field that he needs to fill mandatorily is the “Assigned To” field.  In the
drop down, he will find the entire set of members in the project.  He can assign it to the Project
manager of the project who is the responsible person.  He is also free to assign the issue to any
other person in the project (say for instance, the Technical lead, if this is a technical risk).

Figure3. Identifying a Risk in SynergyOne

Once a risk is identified, this is visible against a person’s profile in SynergyOne.  The “Issues” tab,
available to all the team members in their profile, lists down all the issues in the project.  The user
also has the feature to filter out the risks to suit his viewing convenience.

9 | P a g e

Figure4. Risks viewed in an individual’s profile ‐ XXXX
Risk Analysis and Mitigation
These being a PM function, only the Project Owner, who is the PM, has the permission to edit or
reassign a risk, once it is logged. The PM analyses the risk and puts in the appropriate mitigation
strategies in place. The mitigation plan need not be necessarily implemented by him. However,
identifying the resolution process and tracking it to closure still remains under the ownership of the
Project Manager.
He logs the appropriate mitigation strategy and assigns it to the next person who, he deems can
resolve the risk effectively.
The illustration of a risk identified with mitigation strategy in place is available in Figure5.

10 | P a g e

Figure5. Illustration of a risk with impact analysis and mitigation plan – XXXX
Risk Prioritization
Figure 6 illustrates the risk ranking/prioritization model available in SynergyOne.  This is standard
across the entire set of projects configured through SynergyOne.

As soon as a risk is raised and assigned to the PM, it is visible in the issues tab against his profile.  He
needs to review the risk and identify the probability and criticality of the same according to its
nature.  He also would need to put in a mitigation plan.  This mandatory process ensures that the
PM has put in his thoughts to solve the problem before passing this across to other stakeholders.
Once he has identified a mitigation plan, he can do the following:
 He can resolve the risk if it is completely under his control
 Can reassign the same to another member for appropriate resolution

11 | P a g e

Figure6. Risk Ranking/Prioritization model in SynergyOne

Table1. Status Calibration based on impacts and probability ‐ XXXX

Risk
Prioritization
Type
Account Management,
Client, Technical, Process, Others
Priority
Emergency,
High,
Medium, Low
Budget Impact
High,
Low,
None
Schedule Impact
None, Reduction in Schedule,
Slight schedule slip, Moderate
Schedule Slip, Significant Schedule
Slip
Customer impact
None,
Significant,
Insignificant
Complexity
High,
Medium,
Low

12 | P a g e
Accountability
The process under discussion ensures that there is accountability for the risk at any point in time.
The person accountable is the assignee of the risk or the person to whom it is assigned at a point in
time.
The ownership and accountability is clearly delineated in the process.  The owner is the person who
owns the responsibility of seeing the risk resolution completed through.  The person who is
accountable for a particular risk is the person who is temporarily assigned the responsibility of
resolving the issues and thereby will be responsible for it.
Ownership
The ownership of the risk identified is vested in the Project Owner at any point in time; irrespective
of the status it is in and to whom it has been assigned for resolution.

Risk Escalation
The Project Owner can directly assign a risk to the next level in the tool if the risk resolution is not
under his control.  Any risk that has a potential for high impact should be escalated to the next level
proactively for quick resolution.
Risk Monitoring & Analysis
Since Risk Management is a continuous activity, monitoring of the risks becomes critical.
SynergyOne provides this feature with the help of graphical reports that can provide some high level
metrics as well.

Figure9. Risk Monitoring through SynergyOne ‐ XXXXX

13 | P a g e
Monitoring and Closure
The owner of the project, the Project Manager tracks the issues to closure.  Any resolved risk is
assigned back to the risk owner for his review of the resolution and closure.  The Project Owner
tracks the progress of the risks as appropriate and makes sure that they are closed on time.
From a quantitative management point of view, the tool implemented has great relevance since it
simplifies the analysis and continuous monitoring process.  The dashboard becomes an effective
mechanism to report the health status.
Discussion (Risk Metrics)
The Risk dashboard provides some simple metrics to report the health of the project at any point in
time.  Apart from reporting, the tool facilitates simple analysis like the above that helps identify key
areas to focus on.  This would be an effective lead metrics for the corporate PMO or the Senior
Management to identify the health of the project.
The following are some metrics that can be arrived at:
 % Total Number of Risks open Vs. Total logged:  17%
 % of Critical Risks in the Open Risks Category:  39%
 % of Types of Risks:
o Process breakage risks:  31%
o Technical Risks:  46%
o Client Side Risks: 8%
o Account Management Risks: 6%
The tool also facilitates a peep into the data at the click of the mouse.  A right‐click on the chart will
pop up the detail report of the number of issues logged.  Figure10 illustrates this with a screenshot.

Figure10. Risk Monitoring through SynergyOne ‐ XXXXX

14 | P a g e
Conclusion
Risk management is a critical function in the any software project and this white paper has
dealt with the process followed by XXXX[7] to manage them.  The different steps in risk
management such as identification, mitigation, resolution and monitoring have also been
covered from a practical angle.

Implementation of a web‐based risk management tool from a tracking and monitoring
perspective in a distributed environment is also discussed with highlights on the analysis
that can be achieved.

Bibliography
1. Risk and Risk Management, United States Department of Agriculture A Risk Management Agency Fact
Sheet, May2000
2. A Guide to The Project Management Body of Knowledge, The Project Management Institute, Inc.
(PMI®), http://www.pmi.org
3. http://www.itilfoundations.com/glossaries/itil/
4. Risk Management in IT Projects, Dr.Wallmuller.
5. Software Risk: Why must we keep learning from experience? Don Shafer, Athens Group, Inc
6. Risk Management for IT Projects, Bennet P.Lientz, Lee Larssen, Butterworth‐Hienemann, 2006
7. XXXXX refers to an account where this was implemented in practice.  Name of the account is hidden
for confidentiality reasons.

i
Risk Management for IT and Software Projects, Dr.E Wallmuller, Qualitat und Informatik www.itq.ch,  Zurich.

View publication stats
View publication stats

Case study riskmanagementinpractice-v3

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Case study riskmanagementinpractice-v3

Similar to Case study riskmanagementinpractice-v3 (20)

Recently uploaded

Recently uploaded (20)

Case study riskmanagementinpractice-v3