2012 Eighth International Conference on the Quality of Information and Communications Technology
Collaborative Risk Management in Software Projects
work-in-progress
Pedro Sá Silva, António Trigo
Polytechnic Institute of Coimbra
Coimbra, Portugal
psasilva@esec.pt, aribeiro@iscac.pt
Abstract— Risk Management in software projects has been
increasingly its importance and value, being pointed as an
important basis of project success. However, many projects are
still carried out without giving importance to this knowledge
area. This work discusses some of the main aspects of Risk
Management and introduces the concept of collaborative work
in risk management. It is presented a work-in-progress that
aims to contribute to a better understanding of the different
attitudes towards risk and the impact that this may have on
risk assessment.
Keywords- Project Management, Risk Management,
Software Projects, Risk Identification
I. INTRODUCTION
In their lifecycle, companies develop many projects
under hard conditions. Time pressure, limited budgets and
high stakeholders’ expectations are some examples; all of
them performed in an uncertain and constantly changing
world. Managing all these issues represents a complex and
demanding challenge where the room for error is getting
smaller all the time [1].
Projects have an unpopular reputation of failure,
especially software projects [2-4]. Every year, huge amounts
of financial resources are loss due project’s failures [5-7].
Project’s failures may involve a high waste of material and
intangible resources (e.g. monetary, motivation, and
deterioration of company brand). With the actual economic
reality, these consequences may cause a huge and
irreversible impact on organizations.
Periodically, research results and organizations reports
are published identifying some of the causes behind the
project failures, such as the Standish Group’s CHAOS
Report. The poor attention given to the Risk Management
(RM) throughout the project life cycle is one of top the
problems identified in these studies [2, 3, 5, 8].
There are several references that include and describe
RM best practices, but there is a gap in software tools to help
RM process based on existing models (e.g. PMBoK). For
instance, Microsoft Project 2010 (probably the worldwide
most used PM software) does not include a RM module. The
few existing tools dedicated for RM, such as the Risky
Project and @Risk, are characterized by being data
repositories where the project manager inserts the risk data,
namely its probability, impact and assigned resources. Some
978-0-7695-4777-0/12 $26.00 © 2012 IEEE
DOI 10.1109/QUATIC.2012.24
João Varajão
Centro ALGORITMI
University of Trás-os-Montes e Alto Douro
Vila Real, Portugal
jvarajao@utad.pt
tools implement simulation techniques to help RM, but only
in specific RM processes, without a holistic approach.
Some areas of RM have received high attention in the
literature, as it is the case of the risk identification process
[2]. However, the current methodologies are very dependent
on the projects stakeholders’ sensibility and risk perception.
In software projects this issue is amplified, because of the
many variables that must be considered like, for instance, the
need to deal with new technologies or with new knowledge
areas [9]. Several authors built lists of the most common
errors in RM in software projects. However, they realize that
the perception of risk differs with the type of stakeholders,
culture and time [9, 10].
Simulation can represent an interesting approach to
identify analyze and explore the impact of risks. The risks
can be imitated through a model that allows the analysis and
exploration of new hypotheses without compromising the
real system [11]. For instance, it would be useful to have a
simulation process to enable not only a better risk
identification, but also to enable analyzing how the
combination of risks can lead to new risks (combined or
singular). Moreover, the simulation would also help to get a
better understanding on how the risks evolve over time.
The paper is organized as following. After providing a
work contextualization in the introduction, Section 2 outlines
some of the main concepts, tools and techniques of the Risk
Management (RM) knowledge area. Section 3 describes the
concept and idea of our contribution to Risk Management in
the planning phase. Finally, it will be presented some final
remarks regarding to the proposed work.
II. RISK MANAGEMENT
RM describes a set of methods and techniques to
identify, analyze and manage potential problems before they
occur, increasing the probability of project success [9].
Frequently risk is associated with negative events, excluding
the opportunities it can bring. In the business world, risk is
always present and is considered a condition for progress and
innovation. Risks arise when looking for opportunities with
limited resources in uncertainty contexts. Since we cannot
avoid risks, managing them becomes essential. The
challenge is to balance these factors to generate opportunities
[9].
157
 The main purpose of RM is to maximize the probability
and impact of positive events, minimizing the probability
and impact of negative events and, if they occur, develop an
action plan to handle them [12, 13].
People and organizations react differently with risk,
having different risk attitudes, tolerances and appetites. The
“risk appetite” is the amount of risk that organization (or
person) is able to accept when seeking opportunities. Risk
tolerance is the accepted deviation from the risk level
defined in the risk appetite [14, 15]. These decisions are
influenced by the people risk attitudes, they can be risk-
averse, risk-neutral or risk-seeking [16]. Risk-averse is
someone who are uncomfortable with risk, i.e., the potential
payoff must overcome the utility and pleasure of taking
risks; Risk-neutral is a person who sees risk as a normal
issue when searching for opportunities. Risk-seeking is
someone who prefers taking risks even if the potential payoff
is low. When people are in group they are influenced by the
group decisions. Analyzing the individual risk attitude may
indicate the risk attitude of the group or company.
Currently there are several PM references which
encompass good RM practices, such as, Project Management
Body of Knowledge (PMBoK), Capability Maturity Model
Integration (CMMI), ISO 31000:2009, PRINCE2 and IPMA
Competence Baseline (ICB). From all of these references,
PMBOK stands out for being PM dedicated and providing a
wide and complete set of methods and techniques for RM [8,
12, 17].
All standards propose different names, tools and
techniques however they share a similar RM process,
namely: Risk Management Planning; Risk Identification;
Qualitative Risk Analysis; Quantitative Risk Analysis; Risk
Response Planning; Risks Monitoring and Control [13, 18].
In Risk Management Planning it is developed the overall
strategy for managing risks, describing how to approach,
plan and execute the activities of RM. In this process,
meetings are held with the elements of the project in order to
specify, for instance, methodologies, responsibilities,
resources needs, reporting formats, among others.
Risk Identification is an iterative process that seeks to
identify risks that may affect the project and documenting
their characteristics. Currently there are different techniques
to make the identification of risks such as: brainstorming,
Delphi, interviews, SWOT analysis, checklist, cause-effect
diagram, flowchart, diagram of influence. The output of this
work would be the Risk register.
The Qualitative Risk Analysis purpose is to rank the
identified risks in different levels of priority, according the
risk’s occurrence probability and impact. In this process
several tools and techniques are used, like for instance, the
Probability and Impact Matrix which generates a visual
representation of the result of the series of risks.
The Quantitative Risk Analysis process numerically
analyzes and measures (quantified) the impact of each
identified risk. Decision trees, Earned Value Management
(EVM) and Monte Carlo analysis are examples of techniques
for quantification.
The Risk Response Planning process formalizes the
actions and resources needed if an identified risk occurs.
158
Procedures are described in this plan and allocated resources
for each identified risk in order to reduce the impact of risks
on the project goals. In this process, strategies are defined to
respond to risk, for example, ignore, transfer, share or exploit
risk.
Risks Monitoring and Control process aims to track the
evolution of risks and, if they occur, ensures that they are
handled and mitigated based on the plan outlined in the Risk
Response Planning. This process is performed periodically
with, for instance, auditing, meetings and progress reports.
This is an iterative process that follows the project life cycle
until its completion.
Typically, in the RM process, risks are analyzed singly.
Due to the risks complexity, risks may have relationship
between them, i.e., some risks are related with others risks,
creating a dependency between them. Risk dependency seeks
for these connections and tries to quantify them [19]. For
instance, in a software project, the risk of changing the
Database Management System (DBMS) may be related with
the risk of the DBMS provider failing the requested
development or with the risk of the new version of the
hardware Operating System. The risk dependency can
increase in programs (set of related projects), where a risk in
one project may influence a risk (or more) in another.
III. WORK-IN-PROGRESS
Due the uncertainty context in the last years, Risk
Management (RM) has been highlighted as crucial in Project
Management (PM) [2, 8, 9, 20]. Cerpa and Verner [21]
analyzed unsuccessful projects and identify that 75% did not
give any importance to RM; 70% did not included the RM in
the project plan. Paradoxically in other studies, project
managers point RM as a crucial activity for achieves a
successful project [2, 3, 8, 9, 20]. The current high degree of
uncertainty in the context of implementation of projects, RM
is more important than ever. It thus becomes important to
have models and tools that enable the simulation of risk
scenarios, aiming at a comprehensive assessment of the
threats and opportunities that may arise in implementing the
projects.
The Risk Identification process has been a subject of
interest in the RM research community [2]. The current
methodologies heavily depend on the sensitivity and
perception of those involved in the project. Several works
demonstrated that people have different perception towards
risk and different risk attitudes [9, 10]. Due the uniqueness of
each software project and the fast technological evolution,
many of these projects deal with new technologies or new
areas of knowledge (“known-unknowns”) [9] which will
represent new risks.
In order to capture and analyze the different risk
attitudes, this work aims to develop a model for RM in the
context of software development projects to allow a
Collaborative Risk Management (CoRM) in the planning
phase, specifically: Collaborative Risk Identification;
Collaborative Risk Selection and Combination;
Collaborative Risk Response Strategy. During the entire
process all decisions will be capture in order to understand
the organization risk culture level and the risk attitude of
each project team member. Figure 1 shows an example of the A. Collaborative risk identification
CoRM that is globally explained in the following sections. One of the first activities in a project is defining the
Project goals and project goals and description. This information is very
restrictions important to understand the range and complexity of the
project. Usually this process is developed by the
professionals who are closed to the clients like, for instance,
project leader and consultants (or, in some cases, the entire
Collaborative risk identification: project team).
Risk(1,1): P(1,1) = medium I(1,1) = high With the goals defined, team members, according to their
Risk(1,2): P(1,2) = low I(1,2) = high skills and experience, can start identifying risks that can
/ Risk(1,n): P(1,n)= ? I(1,n)= ? affect the project goals, including the risks which have
positive and negative impact. For each identified risk they
will categorize the risk impact and the probability in a scale:
low, medium and high. In this process, project members
Risk(2,1): P(1,1) = low I(2,1) = high
preform the risk identification alone. This approach may be
Risk(2,2): P(1,2) = medium I(2,2) = medium
useful to determine the risk attitude and risk tolerance of
/ Risk(2,n): P(2,n)= ? I(2,n)= ?
each member or group area, which will allow identifying the
organization global risk tolerance. This will also allow
understanding future decisions and monitoring the risk
/ Risk(n,m): P(n,m)= low, I(n,m)= low, tolerance evolution of the organization.
medium, medium, This stage ends with a first draft of the risk register of
high high each project member, describing the probability and impact.
B. Collaborative risk selection and combination
After generating the preliminary risk records, the project
Collaborative risk selection and leader analyzes all risks and may change, filter or merge
combination some risks. Then him, with the project team, can analyze and
Risk(1): P(1) = medium I(1) = high identify the risk dependencies (identifying the risks that may
Risk(2): P(2) = low I(2) = high be influenced by other risks). The probability and impact
Risk(3): P(3) = low I(3) = medium assessment of the risk will follow the Kwan Wah [22] risk
Risk(4): Risk(1) → Risk(5) dependency theory, used to compute the final combined risk
Risk(n): P(n) = ? I(n) = ? probability and impact. By this way, the project team will be
/
……. able to identify and analyze the risks and evaluate if its
Project Impact
combination can lead to disproportioned project failure.
team low
Negative impacts
medium high
R(6)
high
R(2)
Positive impacts
medium low
After the selection and combination, the project team
high high
will generate the risk probability matrix according to the
R(9) R(1) R(7)
scale (low, medium or high). This matrix gives a visual
Probability
Probability

R(11)
medium medium

representation of the risks rank and helps risk prioritization.

R(8) R(4) R(5) R(10)

low low
The output of this stage is the risk register with the
low medium high high medium low
filtered risks sort by priority.
Negative impacts Positive impacts
Impact

C. Collaborative risk response strategy

Regarding the organization’s risk tolerance and appetite,
Collaborative risk response the project sponsors may analyze and decide what risk or
strategy opportunities they want to explore or ignore. Also they can
Risk(1): Monitor risk add new risks, delete or combine the existing ones, which
Risk(2): Ignore oportunity may require new risk analysis by the project team.
Project Risk(4): Ignore risk According to the risk matrix, project sponsors may want to
sponsors ……. monitor risk/opportunity, reduce the impact of the risk by
taking some previous actions or enhance the
probability/impact of the opportunities. With the project
sponsors decisions about the identified risks, it would be
Plan risk responses possible to analyze some risk relevant issues.
The decisions in this stage will guide the rest of the
organization in terms of RM activities.
…..
Figure 1. Figure 1. Collaborative Risk Management

159
 IV. CONCLUSIONS
Lack of RM has been appointed in the past years has a
major cause for project failure with all it encompasses.
Indeed, project failure can be defined has the result of the
multiplicity of risks inherent to software project environment
[23]. This is not due to the lack of frameworks, best practices
guidelines or even the absence of knowledge of the
importance of risk management by projects managers, but
due to the complexity and time involved (mainly in small
projects).
In order to contribute to improve this situation, are
needed new approaches, agile and collaborative, to enable
project managers and team members to participate in the
assessment of software project risk.
People and organizations have their own risk perception,
tolerance, appetite and attitude regarding risk. Some are
uncomfortable with risk (risk-averse); others face risk as a
normal issue when searching for opportunities (risk-neutral);
and others like the risk even when the probability of success
is low (risk-seeking). These different attitudes will define the
person/organization actions when a potential threat/
opportunity appear. Understanding the risk attitudes of each
person may lead to the understanding of the organization (or
group) risk attitude.
Our work-in-progress highlights the collaborative work
in the risk management, by collecting and store the
individual perception of risk identification and assessment.
As future work we will explore the influence that a group of
individuals has in the risk identification process. This will be
done through the study of real cases of software projects,
which already perform RM according to an existing standard
(PMBoK, CMMI, PRINCE2, etc.). This will provide a
comparative basis with our proposal of work.
REFERENCES
[1] H. Kerzner, Project Management: A Systems Approach to
Planning, Scheduling, and Controlling: John Wiley & Sons, Inc., 2009.
[2] H. Taylor, "Risk management and problem resolution strategies
for IT projects," Project Management Journal, vol. 37, pp. 49-63, 2006.
[3] C. Chapman and S. Ward, "Why risk efficiency is a key aspect
of best practice projects," International Journal of Project Management,
vol. 22, pp. 619-632, 2004.
[4] K. de Bakker, A. Boonstra, and H. Wortmann, "Does risk
management contribute to IT project success? A meta-analysis of empirical
evidence," International Journal of Project Management, vol. 28, pp. 493-
503, 2010.
[5] R. N. Charette, "Why software fails," Spectrum, IEEE, vol. 42,
pp. 42-49, 2005.
160
[6] SG. (2009). Standish Newsroom - CHAOS 2009. Available:
http://www1.standishgroup.com/newsroom/chaos_2009.php
[7] J. L. Eveleens and C. Verhoef, "The rise and fall of the Chaos
report figures," IEEE Software, vol. 27, pp. 30-36, 2010.
[8] C. Rodrigues, I. Teles, J. B. Cruz, and J. Varajão, "Risk
Management in scope of Project Management," presented at the 6th
International Conference on Information Systems and Technology
Management Brazil, 2009.
[9] P. L. Bannerman, "Risk and risk management in software
projects: A reassessment," Journal of Systems and Software, vol. 81, pp.
2118-2133, 2008.
[10] M. Keil, A. Tiwana, and A. Bush, "Reconciling user and project
manager perceptions of IT project risk," Information Systems Journal, vol.
12, pp. 103-119, 2002.
[11] S. Robinson, "General concepts of quality for discrete-event
simulation," European Journal of Operational Research, vol. 138, pp. 103-
117, 2002.
[12] C. G. von Wangenheim, D. A. d. Silva, L. Buglione, R. Scheidt,
and R. Prikladnicki, "Best practice fusion of CMMI-DEV v1.2 (PP, PMC,
SAM) and PMBoK 2008," Information and Software Technology, vol. 52,
pp. 749-757, 2010.
[13] PMI, Practice Standard for Project Risk Management: Project
Management Institute, Inc., 2009.
[14] ISACA, The Riks IT Practitioner Guide: ISACA, 2009.
[15] ISO, "ISO GUIDE 73:2009," ed: International Organization for
Standardization, 2009.
[16] K. Schwalbe, Information Technology Project Management, 6
ed.: Course Technology, 2010.
[17] M. Leitch, "ISO 31000:2009—The New International Standard
on Risk Management," Risk Analysis, vol. 30, pp. 887-892, 2010.
[18] PMI, A Guide To The Project Management Body Of
Knowledge (PMBoK Guides), Fourth edition ed.: Project Management
Institute, Inc., 2008.
[19] K. T. Wah and H. K. N. Leung, "A Risk Management
Methodology for Project Risk Dependencies," IEEE Transactions on
Software Engineering, vol. 37, pp. 635-648, 2011.
[20] C. H. Loch, A. DeMeyer, and M. T. Pich, Managing the
Unknown: A New Approach to Managing High Uncertainty and Risk in
Projects: John Wiley & Sons, Inc., 2006.
[21] N. Cerpa and J. M. Verner, "Why did your project fail?,"
Communications of the ACM, vol. 52, pp. 130-134, 2009.
[22] K. Tak Wah and H. K. N. Leung, "A Risk Management
Methodology for Project Risk Dependencies," IEEE Transactions on
Software Engineering, vol. 37, pp. 635-648, 2011.
[23] Y. H. Kwak and J. Stoddard, "Project risk management: lessons
learned from software development environment," Technovation, vol. 24,
pp. 915-920, 2004.