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 READS
0 4,649

1 author:

Sreekumar Parameswaran Pillai

National Institute of Technology Calicut
7 PUBLICATIONS   0 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Statistics Tools View project

Philosophy, Psychology, Mysticism View project

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  July 27 

Management  2009 
in Practice 
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 
Risk 
for project failures, risk management deserves a special attention.  Management 
More than an exposition of theoretical discussions on the  in Practice: 
different Risk management models, this paper focuses on the 
process followed in the XXXXX[7] account and practical  Process and 
implementation of the risk management process through features 
available in Innotas, a commercial PPM [Program Project 
Tools 
management tool]. 
This case study takes one through the risk management functions 
from process to process implementation sequentially.  
 

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. 

2 | P a g e  
© 2009, Sreekumar Parameswaran Pillai 
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.  

Risk 
Identification

Risk Assessment Risk Analysis

Risk 
Prioritization
Risk 
Management
Risk 
Management 
Planning

Risk Control Risk Resolution

Risk Monitoring

 
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. 
   

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

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 
4 | P a g e  
© 2009, Sreekumar Parameswaran Pillai 
 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. 
 

5 | P a g e  
© 2009, Sreekumar Parameswaran Pillai 
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] 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 
 
 

6 | P a g e  
© 2009, Sreekumar Parameswaran Pillai 
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 
7 | P a g e  
© 2009, Sreekumar Parameswaran Pillai 
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. 

8 | P a g e  
© 2009, Sreekumar Parameswaran Pillai 
  
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. 
 

9 | P a g e  
© 2009, Sreekumar Parameswaran Pillai 
  
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 

10 | P a g e  
© 2009, Sreekumar Parameswaran Pillai 
 Account Management, 
Type
Client, Technical, Process, Others

Emergency, 
Priority High,
Medium, Low

High,
Budget Impact Low,
None
Risk 
Prioritization
None, Reduction in Schedule,  
Slight schedule slip, Moderate 
Schedule Impact
Schedule Slip, Significant Schedule 
Slip

None, 
Customer impact Significant,
Insignificant

High,
Complexity Medium, 
Low
 
Figure6. Risk Ranking/Prioritization model in SynergyOne 

 
Table1. Status Calibration based on impacts and probability ‐ XXXX 

   
11 | P a g e  
© 2009, Sreekumar Parameswaran Pillai 
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 

   

12 | P a g e  
© 2009, Sreekumar Parameswaran Pillai 
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 

13 | P a g e  
© 2009, Sreekumar Parameswaran Pillai 
 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. 

14 | P a g e  
© 2009, Sreekumar Parameswaran Pillai 
View publication stats