Enhancing dotProject to support Risk Management aligned

with PMBOK in the context of SMEs

Rafael Queiroz Gonçalves, Elisa Kühlkamp, Christiane Gresse von Wangenheim

Graduate Program on Computer Science (PPGCC), Department of Informatics and Statistics,

Federal University of Santa Catarina, Florianópolis, Brazil

rafael.queiroz@posgrad.ufsc.br, elisafk1@gmail.com, gresse@inf.ufsc.br

Abstract: Many problems in software development projects are due to risks and could be

avoided or minimized if identified and treated pro-actively. In this context, software tools to

support risk management could be very helpful. However, it is difficult to find a project

management tool, accessible to Small and Medium Enterprises (SMEs) that provides adequate

support to risk management in conformance with best practices such as the PMBOK.

Therefore, this paper has the objective to review support provided by popular project

management tools with respect to risk management and to present enhancements made to the

open-source tool – dotProject – in order to systematically support risk management aligned

with the PMBOK. An initial evaluation identified benefits in the implementation of risk

management processes in software SMEs, and, thus, contributing to their projects’ success.

Keywords: Risk Management; PMBOK; dotProject; open-source; SMEs; project management

tool.

1. Introduction

Many problems in software projects are caused through risks and could be avoided or minimized, if they

are identified and treated in advance (Cristina and Salmeron, 2012). Initiating a project without

proactively focusing on risks not only increases the probability of risks occurring, but also the impact

they may have on the project, and, thus, the chances of project failure (Persson et al., 2009; Öbrand et al.,

2012). A risk is an uncertainty, whose materialization can negatively impact on the project plan (Jalil and

Hanif, 2009). For example, if hardware prices increase, the project may come in over budget or if a key

software analyst becomes ill, critical activities may be delayed. The probability of a risk is the chance it

happens, whereas the risk impact indicates what will be affected in the project (e.g., schedule, budget, or

quality) and to what degree. Risk management serves to identify the risks to which the project is exposed

to, and to plan actions to minimize the impact or even avoid them happening (PMI, 2013). It consists of a

set of processes, responsible for identifying the project risks, analysing them, planning risk responses, and

to control risks throughout the project execution (PMI, 2013).

Yet, risk management is still underutilized in the software sector (PMI, 2010), where the majority of

enterprises approaches risk management informally. This issue is even more severe as typically most

software organizations are Small and Medium Enterprises (SMEs) with limited resources (SEBRAE,

2013; SOFTEX, 2012).

And, although, there exist various guides on risk management (such as the PMBOK (PMI, 2013)),

comprehensive tool support for the adoption of risk management is basically only available through

commercial tools such as MS-Project (microsoft.com/project) or Primavera (oracle.com/primavera). Yet,

due to their price, such tools may be not suitable to the budget of many SMEs (Fabac et al., 2010). On the

other hand, open-source project management tools such as dotProject (dotproject.net), project.net

(project.net), or phpCollab (phpcollab.com) also provide some kind of risk management, yet, are less

complete and generally not in conformity with best practice guides such as the PMBOK (Pereira et al.,

2013). However, due to their low cost and flexibility, they may represent an interesting alternative

especially for SMEs.

One of the most popular and comprehensive open-source tools is dotProject, a web-based tool for

project management. However, dotProject is also far from supporting completely the project management

process as proposed by the PMBOK (Dippelreiter et al., 2010; Wangenheim et al., 2009). Especially for

risk management, dotProject itself does not provide any support (Pereira et al., 2013). And, although,

there exist an add-on module that provides basic support to risk management for risk registering and

reporting (SOURCEFORGE, 2013), it is still far from providing comprehensive support.

In this context, this paper summarizes the state of the art of the support provided by open-source tools

for risk management and provides a proposal of how to support the risk management process by

enhancing dotProject’s functionalities in conformance with the PMBOK customized to the context of

SMEs.

2. Background

This section briefly introduces the main concepts used in this paper, such as project management and risk

management.

2.1. Project Management

Project management is the use of knowledge, abilities, tools, and techniques in order to make project

activities meet their requirements (PMI, 2013). A project is defined as a temporary effort undertaken to

create a single result. The project management life cycle is composed of 5 processes groups (Figure 1):

Initiation: to start a new project or phase and to obtain authorization for its execution.

Planning: to establish project goals and scope and to define the actions for the project to meet its

goals.

Execution: to conduct the necessary work to carry out the activities in the project plan.

Monitoring and Controlling: to monitor, review, and adjust the project performance and its progress

through corrective actions.

Closing: to finish all project activities or phases in a formal way.

Figure 1 Project management life cycle (PMI, 2013)

Furthermore, project management processes are grouped into 10 knowledge areas (PMI, 2013):

integration, scope, time, cost, quality, human resources, communication, risk, supplier, and stakeholders.

In this context, this paper focuses specifically on the risk knowledge area.

2.2. Risk Management

Based on best practices as proposed by the PMBOK (PMI, 2013) and taking into consideration

characteristics of SMEs in the software domain (SEBRAE, 2013; Raz and Michael, 2001), a high-level

risk management process is defined (Figure 2). The process identifies relevant (sub-)processes as well as

relevant artefacts (process inputs/outputs) and tools/techniques in the context of SMEs. The process is

described using the SPEM notation (http://omg.org/spec/SPEM).

Figure 2 Generic process model for risk management in SMEs

The process plan risk management defines how to direct risk management activities in the project.

The risk management plan is an artefact that includes guidelines to identify, analyse, planning responses

and controlling risks. It is normally defined in meetings, involving the project manager, team members

and other stakeholders. This plan defines risk categories, using, e.g., a simple list or a Risk Breakdown

Structure (RBS), representing a hierarchical decomposition of risk types (Figure 3).

Figure 3 RBS example (PMI, 2013)

The risk management plan also includes classification schemes for probability and impact levels

(Table 1), which are later estimated during the process perform qualitative risk analysis.

Table 1 Example of classification schemes using an ordinal scale

Classification of impact levels

Very high Extreme event, which may generate costs or schedule delays, or even deteriorate

the organization image.

High Critical event, which may generate some cost or schedule delay, or non-appropriate

products.

Medium Great impact, which may be handled with some effort, using standard procedures.

Low Minimal impact that may be handled with standard procedures.

Very Low The impact can be ignored.

Classification of probability levels

Very high A similar event has happened many times in the same activity or operation.

High A similar event has happened many times in the organization.

Medium A similar event already happened once in the organization.

Low A similar event has happened in a similar organization.

Very Low A similar event happened once in another organization.

It is also planned how to define the exposition factor, a risk attribute used to define the risk priority,

based on its estimated probability and impact. This factor is typically derived using a probability and

impact matrix (Table 2), which shows, for every combination of probability and impact, the respective

exposition factor.

Table 2 Example of probability and impact matrix

Probability

Very High High Medium Low

Imp

act

Very High High High High Medium

High High High Medium Low

Medium High Medium Medium Low

Low Medium Low Low Low

Exposition Factor

During the process identify risk the risks that could affect the project are determined. Techniques used

in this process include brainstorming and checklist analysis (PMI, 2013). During checklist analysis,

current risks are identified based on risks already identified in previously projects. The process output is a

risk record, normally describing the risks by identifying their cause and consequence(s) (Table 3).

Table 3 Example of risk record

Risk record

Risk title Misunderstanding of the requirements.

Cause Conflict between requirements providers.

Consequence The software quality will not meet the stakeholders’ expectations.

Once the risks have been identified, they are analysed and prioritized. The analysis can be done in a

qualitative and/or quantitative manner. The first step of the process perform qualitative risk analysis is to

estimate the risk probability and impact, which generally happens in brainstorming meetings. Based on

those estimations the exposition factor is identified using the probability and impact matrix. The main

output of this process is a list of prioritized risks.

The process perform quantitative risk analysis aims at numerically evaluate risk effects on the

project. However, today the majority of software SMEs do not fulfil necessary pre-conditions to apply

this process (Han et al., 2008; Marcelino-Sádaba et al., 2014), as they often do not record historical data

of previous projects. This process is typically used only in more mature organizations, for example, on

CMMI-DEV maturity level 4 and 5 (SEI, 2010), which so far very few SMEs have achieved. For this

reason, this process is not considered relevant currently in the context of SMEs in the software domain.

During the process plan risk responses it is defined how to prevent and to treat the risks with a high

exposition factor. A risk prevention plan is defined for all of these risks, in order to either reduce the

probability of the risk occurrence or its impact. Response strategies vary from eliminate (the risk cause

can be avoided), transfer (delegate the response responsibility to a third party), mitigate (define actions to

minimize the impact), to simply accept (e.g., when the cost to prevent the risk is higher than its impact).

For any risks to be mitigated, a contingency plan is defined. This also includes the identification of a

trigger indicating the risk occurrence. All other risks for which no explicit responses are defined are kept

on a watchlist and are analysed periodically to verify if some those risk happened and need to be treated.

During the process control risk the risk response effectiveness is evaluated and it is verified whether

some trigger was fired, in which case the planned response have to be initiated. This process is carried out

during monitoring meetings, assisted by a checklist to conduct the re-evaluation of risks, identifying if

new risks appeared, reviewing existing risks, and closing outdated risks.

3. State of the Art

This section analyses popular tools for project management and discusses the provided support for risk

management. The most popular tools were chosen based on a survey of the Project Management Institute

(PMI, 2010), focusing on web-based tools as they enable the provision of multiuser support. The tools we

analysed are: MS-Project Server, Oracle Primavera, and dotProject.

3.1. Requirements for Risk Management Support by Project Management Tools

To analyse the tools in relation to the process model for risk management with focus on SMEs, we

identify in a first step the necessary software requirements. The requirements have been elicited in a

systematic way analysing mainly the artefacts to be produced as defined by the process model presented

in section 2.2, identifying how the creation of the artefacts can be supported by the software and how the

artefacts can be made available for the involved stakeholders during the process. In a second step the

initial requirements were discussed with other project management specialists. As it is not possible at this

point due to the maturity level of software organizations currently to completely automatize the risk

management process, we propose a semi-automated support, where the artefacts can be registered during

the execution of the process by the relevant stakeholders.

Table 4 Requirements for risk management tool support

Process Functional Requirement

Plan risk

management

FR01 The system must support the creation of the RBS.

FR02 The system must support the definition of probability and impact scales.

FR03 The system must support the probability and impact matrix.

Identify risks FR04 The system must support risk recording, containing fields for risk description

(cause and consequence).

FR05 The system must support the categorization of the risks according to the RBS.

FR06 The system must support the checklist analysis technique, enabling the

identification of risks already registered in previous projects.

Perform

qualitative risk

analysis

FR07 The system must support the registration of the estimated probability and

impact of risk.

FR08 The system must automatically identify the risk exposition factor based on the

probability and impact matrix.

Plan risk

responses

FR09 The system must support the registration of the response strategy.

FR10 The system must support the registration of the prevention and the

contingency plan.

FR11 The system must support the registration of the risk triggers.

FR12 The system must support the creation/modification/deletion of a watchlist and

its items.

Control risks FR13 The system must support the periodical registration of minutes from risk

monitoring meetings.

FR14 The system must support the use of a checklist during monitoring meetings,

containing items to evaluate if there are new risks and to track the risk

responses.

FR15 The system must provide reports to support the risks monitoring, such as the

list of risks with high exposition factor, the planned responses of materialized

risks, and the triggers of high probability risks.

We compare the support provided by the evaluated tools using a 4 points ordinal scale (Table 5).

Table 5 Evaluation scale

Scale Description

- Does not provide any support.

* Offers basic support, covering less than half of the process.

** Covers more than half of the process.

*** Offers a complete set of elaborate functionalities for the process.

The tool analysis has been carried out by the authors based on experiences with the tools usage. For

tools that authors have no direct access, this was carried out by the analysis of its functionalities described

in the official material available in the enterprises web site. The results has been reviewed and discussed

with other researches of the Quality Software Group (GQS) at the Federal University of Santa Catarina

(UFSC).

3.2. MS Project Server

MS Project Server (office.microsoft.com/project) is a project management tool that is designed to be

installed in Microsoft SharePoint application server and Microsoft SQL server. The main functionality of

this tool is the schedule development (Figure 4), that is assisted by other functionalities, such as definition

of team members, risk recording, and definition of person/hour rate. It supports the update of the

activities progress and the creation of schedule baseline.

Figure 4 Project record in MS Project Server 2013

Risk management is supported by enabling the registration of the identified risks, using the risk form

(Figure 5). The process perform qualitative risk analysis is supported by recording the estimated

probability and impact levels. The process plan risk responses is supported by the assignment of the risk

owner and the definition of the prevention and contingency plans.

Figure 5 Risk record in MS Project Server 2013

The evaluation of MS-Project Server support is summarized in Table 6.

Table 6 Evaluation of MS-Project Server

Process Evaluation Explanation

Plan risk management - -

Identify risks ** Supports the risk registration (FR04). But does not support

checklist analysis (FR06), and risk RBS categorization

(FR05).

Perform qualitative risk

analysis

** Supports the register of probability and impact estimations

(FR07), but does not support the definition of the exposition

factor (FR08).

Plan risk responses ** It supports the definition of prevention and contingency

plans (FR10), and triggers (FR11). It does not support a

watchlist (FR12), nor the explicit definition of response

strategy (FR09).

Control risks - -

3.3. Oracle Primavera

Oracle Primavera (oracle.com/primavera) is a portfolio management tool for organizations that manage

many projects (Figure 6). The software was designed to work with Microsoft SQL server or an Oracle

database. It offers specialized support for sectors as engineering and construction, oil and gas, public

transport, and financial services. Its main functionalities are: portfolio management, schedule

development, resources management, cost control, contact management, and risk analysis.

Figure 6 Project record in Oracle primavera

Risk management is supported by the Risk Analysis module (Figure 7) (ORACLE, 2013). This

module supports the process identify risks, providing functionalities to include new risks and to use

checklist analysis. The process qualitative risk analysis is supported allowing the registering of the

estimated impact and probability.

Figure 7 Risks list in Primavera

The tool also supports quantitative analysis through Monte-Carlo simulations, and numerical

definitions for probability and impact levels. The tool supports the process plan risk responses by

allowing to register prevention and contingency plans. Risk control is supported by reports and graphics

to track risks with higher probability and to analyse financial impact. It also supports the automated

adjustment of the project schedule considering risk impacts. The evaluation of support provided by

Oracle Primavera is summarized in Table 7.

Table 7 Evaluation of Oracle Primavera

Process Evaluation Explanation

Plan risk management - -

Identify risks *** It supports the registering of risks (FR04) and checklist

analysis (FR06). It does not support risk RBS

categorization (FR05).

Perform qualitative risk

analysis

*** It supports the register of the estimated probability and

impact (FR07). It also supports registering the exposition

factor using a numeric mode (named as score) (FR08).

Plan risk responses *** It supports the definition of contingency (FR10) and

response plans (FR09), as well as triggers (FR11) and the

management of a watchlist (FR12).

Control risks ** It provides reports to track risks, and analytical graphics

(FR15). It does not provide risks monitoring minutes

(FR13) with the assistance of a checklist for risks review

(FR14).

3.4. DotProject

DotProject (www.dotproject.net) is an open-source tool for project management. The tool supports the

registration of projects and customers, user management, hierarchical definition of project activities, and

the visualization of project schedule (Gantt). It supports the management of a contact list, files repository,

and events calendar. The software was designed for MySQL database server, and was programmed in

PHP. The tool is organized in modules. Its basic functionalities are supported by core modules, and new

functionalities are introduced using add-on modules (dotProject, 2010; Becker et al., 2009). It is

published under the General Public License (GPL) v3.

Figure 8 Project record in dotProject

Among open-source solutions, this is one of the most popular project management tools (Costa et al.,

2009). In 2013, the tool had a download rate of over 5500/per month (SOURCEFORGE, 2014).

Risk management is not supported by any of the core modules. However, there exists an add-on

module, released in 2005, allowing to register project risks (Figure 9) (SOURCEFORGE, 2013).

Figure 9 Risks add-on module

The add-on module (Table 8) supports the process identify risk by registering a project risk list.

Qualitative risk analysis is partially supported by enabling the registering of the estimated probability and

impact. No further risk management process is supported.

Table 8 Evaluation of dotProject with add-on

Process Evaluation Explanation

Plan risk management - -

Identify risks ** Supports the risk recording (FR04), however does not

support checklist analysis (FR06) nor risk RBS

categorization (FR05).

Perform qualitative risk

analysis

** Supports the registration of the probability and impact

estimation (FR07), but does not support the definition of

an exposition factor (FR08).

Plan risk responses - -

Control risks - -

3.5. Discussion

The evaluation shows that these popular tools provide support for risk management on different levels.

The processes identify risks and perform qualitative risk analysis are commonly supported by all

evaluated tools. Nonetheless, it seems that commercial tools provide a more complete support for risk

management than one of the most prominent open-source tools. Both commercial tools support the

process plan risk responses. However, the process plan risk management is not completely supported by

any of the evaluated tools, mainly, missing functionalities to configure the probability and impact matrix

and define the RBS. The process control risks is satisfactorily supported only by Oracle Primavera,

through risks reports, and analytical graphics.

Table 9 Comparison of the evaluated tools

Tools

Processes MS Project Server

2013

Oracle Primavera dotProject add-on

Plan risk management - - -

Identify risks ** *** **

Perform qualitative risk analysis ** *** **

Plan risk responses ** *** -

Control risks - ** -

Oracle primavera has shown to provide almost complete support for the risk management process.

However, as due it price it may not be accessible for SMEs. Therefore, a more viable solution for this

kind of organization may be the enhancement of an open-source tool.

4. Enhancing dotProject to Support Risk Management

Therefore, we have been systematically developing new functionalities in an add-on module, named

dotProject+. The goal is to attend the requirements to support the risk management process in conformity

with the PMBOK’s best practices customized to the context of SMEs as described in section 2.2.

4.1. Plan Risk Management

In order to support this process it is necessary to produce a risk management plan, which contains the

probability and impact scales (FR02), the RBS definition (FR01), and the probability and impact matrix

(FR03). The probability and impact scales are defined on 5 levels, from very low to very high, for which

the criteria have to be defined (Figure 10).

Figure 10 Probability and impact scale in dotProject+

The probability and impact matrix (Figure 11) is generated automatically, and then needs to be

configured the exposition factor for each combination of probability and impact levels.

Figure 11 Probability and impact matrix in dotProject+

We also added a functionality that allows to define a RBS (Figure 12) using a hierarchical list,

defining categories used for risks classification.

Figure 12 Risks Breakdown Structure in dotProject+

To facilitate its creation, this form is initially created with default values, allowing their modification

in accordance to the specific needs of an organization.

4.2. Identify Risks

The support for this process consists in enabling the registration of identified risks (FR04), after a

brainstorming meeting, and/or the use of checklist analysis (FR06) (Figure 13). This functionality initially

presents risks already registered in previous projects, so that they can be reused in the current project.

Risks presented in this checklist are organized by RBS categories.

Figure 13 Support to checklist analysis on dotProject+

To register new risks, a risk form was developed (Figure 14) that allows to detail the risk, classify it

accordingly to the RBS (FR05), and to relate it to affected project activities.

Figure 14 Form to register new risks in dotProject+

4.3. Perform Qualitative Risk Analysis

To support this process it is necessary that each identified risk can be associated with the probability and

impact estimate (FR07), which are identified in estimation meetings. Once registered, it automatically

sets the risk exposition factor using the probability and impact matrix (FR08) (Figure 15).

Figure 15 Qualitative risk analysis in dotProject+

4.4. Plan Risks Responses

The support for this process includes the definition of the risk owner, definition of the response strategy

(FR09), the description of the prevention and/or contingency plan (FR10), and the identification of risk

triggers (FR11). To support this, the tool provides a section to register this information in the risk form

(Figure 16). In case the response strategy is “accept”, the fields related to risk responses are disabled. The

tool also supports the watchlist (FR12), containing the risks evaluated with medium/low priority.

Figure 16 Risk response planning in dotProject

4.5. Control Risks

This process is expected to support the registration of the results of monitoring meetings. Registering

such minutes is assisted by a checklist, containing items for risk re-evaluation, and to verify if the risks

responses are being correctly carried out. To assist in such monitoring the project risks may be presented

in reports, highlighting the ones with high probability and its triggers. The tool was enhanced to support

those needs, including a checklist in the monitoring of meeting minutes (FR13). This checklist includes

items to verify if there are new risks, or if the existing risks need to be changed, and also to verify if the

prevention and contingency plans are being followed (FR14) (Figure 17).

Figure 17 Checklist in the monitoring meeting minute in dotProject+

To assist risks monitoring, the tool provides a risks monitoring panel (FR15) (Figure 18), which uses

dashboards to resume the risks by category (according with RBS), and the amount of risks with high

exposition factor. In addition, the list of risks that need a short term answer, triggers of risks with high

priority, and the watchlist are also provided in the same panel.

Figure 18 Panel for monitoring risks in dotProject+

These enhancements are publically available via dotmods (sourceforge.net/projects/dotmods/), under

the directory “Alignment with PMBOK and CMMI-DEV”. The modules are under the license GPL-GNU,

indicating that the source code can be used and adapted.

5. First Evaluation

This section presents an initial evaluation of the enhancements made to dotProject to support the risk

management process. Two kinds of evaluation were carried out: one via an expert panel, and the other as

a theoretical evaluation, using the same criteria as in the state of art.

5.1. Expert panel evaluation

To define measures and then analyses the answered questions by the experts, the GQM (Goal, Question,

Metric) method (Basili et al., 1994) was adopted. The GQM is a method that initially identifies the goals,

and then, defines questions and measures the responses. In the first step of this method, the goals are

defined:

Goal 1: To analyse the utility of the module to carry out the risk identification (risks record and the

list of identified risks).

Goal 2: To analyse the utility of the module to carry out qualitative risk analysis.

Goal 3: To analyse the utility of the module to plan risk responses.

Goal 4: To identify the strengths and the improvement suggestions of the proposed solution.

For each of the goals, relevant questions have been defined (Table 10).

Table 10 Questions for the goals

Goals Questions

Goal 1 1.1 Is the required information during the risks creation useful?

1.2 Is the identified risks list useful for carrying out the risk analysis?

1.3 Is the module useful for identifying risk?

Goal 2 2.1 Is the risks classification by exposition factor useful?

2.2 Is the watchlist useful?

2.3 Is the list of risks that need a short term answers useful?

2.4 Is the module useful for carrying out the qualitative analysis?

Goal 3 3.1 Is the learned lessons list useful?

3.2 Is the module useful in planning risks responses?

Goal 4 4.1 What are the main strengths observed?

4.2 What are the main improvement points observed?

The identified questions have been reformulated in form of affirmations and using a 5 points likert

scale (1 - total disagreement to 5 - total agreement), a questionnaire has been designed for data collection.

The evaluation has been carried out by project management experts working in software SMEs. The

participants have been chosen by their availability to participate on a short term and participated

voluntarily. They received the evaluation guide, which explains how the risk management processes are

supported by the enhanced tool and used dotProject+ for the process execution. In the end, they answered

the designed online questionnaire. The evaluation has been carried out by 5 experts, in April 2012,

including partial results of this work. The medians of the experts’ answers are presented in Table 11.

Table 11 Median of expert’s answers

Question Median

1.1 Is the required information during the risks creation useful? 5

1.2 Is the identified risks list useful for carrying out the risk analysis? 5

1.3 Is the module useful for identifying risk? 4

2.1 Is the risks classification by exposition factor useful? 4

2.2 Is the watchlist useful? 5

2.3 Is the list of risks that need a short term answers useful? 5

2.4 Is the module useful for carrying out the qualitative analysis? 5

3.1 Is the learned lessons list useful? 5

3.2 Is the module useful in planning risks responses? 4

Analysing the experts’ answers, we can observe that they consider the risk add-on module useful to

carry out risks identification (Goal 1) and the qualitative risk analysis (Goal 2), as well as to plan risks

responses (Goal 3). Among the main strengths cited by the experts, is that the developed module provides

support to register detailed information related to risks, registering not only the risk itself, but also the

response strategy. Among the improvement suggestions is the need to support also the registration of

positive risks and their impact on the project goals.

5.2. Theoretical evaluation

The theoretical evaluation aims at evaluating the risk management support in conformance with the

PMBOK. This evaluation was conducted by the authors, applying the same criteria used to evaluate the

state of art (Table 4). The supported functionalities for each process are highlighted (Table 12).

Table 12 Evaluation of dotProject+

Process Evaluation Functional

Requirement

Explanation

Plan risk

management

*** FR01 Supports the elaboration of the RBS, and the registering

of guidelines for risks controlling.

FR02 Supports the definition of probability and impact scale

and its criteria.

FR03 Supports the probability and impact matrix definition.

Identify risks *** FR04 Supports the risk registering, including fields to detail,

to specify its period and its owner, and the affected

activities.

FR05 Supports the risk classification accordingly the RBS

category.

FR06 Supports the checklists analysis technique.

Perform

qualitative risk

analysis

*** FR07. Supports the registering of the risk estimated

probability and the impact.

FR08 Supports the automatic definition of the risk exposition

factor according with the probability and impact matrix.

Plan risk

responses

*** FR09 Supports the definition of the strategy plan.

FR10 Supports the registering of the prevention and

contingency plans.

FR11 Supports the registering of risk triggers.

FR12 Supports the watchlist.

Control risks *** FR13 Supports the registering of minutes for the monitoring

meetings.

FR14 Provides a checklist for risk monitoring and controlling.

FR15 Provides reports and graphics to assist in the analysis of

the risks and its responses.

Analysing the support provided for each process, we can concludes that the enhanced module

provides complete support for all risk management processes considered relevant in the context for

SMEs.

6. Discussion

Our initial tool evaluation indicates that risk management is reasonably supported by analysed project

management tools. Commercial tools seem to provide more complete support than the open-source tool,

we evaluated. However, if considered the enhanced version of dotProject, there is now a comprehensive

solution for risk management support available as an open-source alternative. dotProject+ provides

support aligned with the PMBOK for all risk management processes, only with the exception of the

quantitative risk analysis process, which, however, has been identified as irrelevant at the current point of

time in the context of SMEs. Results of our first initial evaluation of dotProject+ have also turned out

very positive. In addition, the number of more than 500 downloads of our add-on module for risk

management since its publication in July 2012 on dotmods, the official dotProject add-on modules

repository, also demonstrates the demand for such an extension of a popular open-source tool.

However, in order to effectively improve risk management in SMEs, it is important to point out that,

of course, the adoption of a tool is not sufficient and has to take place as part of a process implementation.

Tool support is only intended to provide support in a semi-automated manner to the execution of risk

management processes to be done by relevant stakeholders. In this context, the risk management module

can be considered as an information repository, which allows to register and to provide artefacts related to

the risk management process.

6.1. Threats to validity

Our research represents a first step to improve systematically an open-source project management tool.

However, due to practical constraints, several research design decision may represent a threat to the

validity of our results. The evaluation of dotProject+ is considered just an initial indication that the risk

management process is adequately supported by dotProject+. One of the threats is that the theoretical

evaluation of the enhancements was conducted by the same authors, and, therefore, may be biased to the

benefits provided by the new module. The expert panel was composed of only 5 experts and, therefore,

does not provide a representative sample. However, our intention here was rather to receive a first

feedback. We are planning a larger scale evaluation once completed enhancements also related to other

knowledge areas. Another issue that may have biased the evaluation results is the general usability of

dotProject being considered rather low as it lacks attractiveness and violates several usability heuristics

(Bozhikova et al., 2009). Thus, in some cases the opinion of evaluators may have been influenced through

the lack of usability rather than being related to the functionality being evaluated.

7. Conclusions

This work attempts to facilitate the adoption of systematic risk management in SMEs in conformance

with PMBOK’s best practices. Therefore, we analysed and adapted the risk management process to the

specific characteristics of SMEs in the software domain. We, furthermore, analyzed the support provided

by three of the most prominent project management tools. Selecting an open-source tool as a more viable

solution for SMEs, we implemented enhancements in conformity with PMBOK. An initial feedback

indicates that the enhancement may contribute positively to the support provided by such an open-source

tool, creating a solution that may easily adopted by SMEs to facilitate the enactment of risk management

also in this kind of organization.

Acknowledgment

This work was supported by the CNPq (Conselho Nacional de Desenvolvimento Científico e Tecnológico

– www.cnpq.br), an entity of the Brazilian government focused on scientific and technological

development.

References

Basili, V., Caldiera, G., and Rombach, D (1994) The Goal Question Metric Approach. Encyclopedia of

Software Engineering,. 2 (9), 528-532.

Becker, J., Niehaves, B., Wienbergen, F., and Matzner M (2009) Open Source Public Sector Business

Intelligence Systems. Chap. in Information Systems Development: Challenges in Practice,

Theory,and Education, 379-391. NewYork City: Springer. doi: 10.1007/978-0-387-68772-8_29.

Bozhikova, V., Stoeva, M., and Tsonev, K. (2009) A practical approach for software project

management. In: Proceedings of the 9th

International Conference on Computer Systems and

Technologies and Workshop for PhD Students in Computing, 18-19 June 2009. Ruse, Bulgaria.

Costa, J., Amaral, C., and Rozenfeld, H (2009) Best practice for selecting software to support NPD

process management. Product: Management & Development, 6 (1), 53-66.

Cristina, L., and Salmeron, J (2012) Risks Response Strategies for Supporting Practitioners Decision-

Making in Software Projects. In: Proceedings of the Conference on ENTERprise Information

Systems, 3-5 October 2012. Algarve, Portugal, 437–444. doi: 10.1016/j.protcy.2012.09.048.

Dippelreiter, B., Grün, C., and Pöttler., M (2010) A ‘state of the art’ Evaluation of PM – Systems

exploring their missing Functionalities. In: Proceedings of the 5th

International Conference on

Project Management, 12-15 October 2010. Tokyo, Japan.

dotProject (2010) Add-on Modules. dotProject.

http://docs.dotproject.net/index.php?title=Category:AddOn_Modules. Accessed 12 December

2013.

Fabac, R., Radoševi D., Pihir I (2010) Frequency of Use and Importance of Software Tools in Project

Management Practice in Croatia. In: Proceedings of the 32nd

International Conference on

Information Technology Interfaces, 21-24 June 2010. Cavtat, Croatia.

Han, G., Wu, Q., Le, Z., Ding, J., and Chen, R (2008) A New Quantitative Analysis Method for Financial

Risk Early Warning of Unlisted Small and Medium Enterprise. In: Proceedings of the 2008

International Conference on Management of e-Commerce and e-Government, 17-19 October

2008. Nanchang, China. 289-296. doi: 10.1109/ICMECG.2008.36.

Jalil, Z., and Hanif, A (2009) Improving Management of Outsourced Software Projects in Pakistan. In:

Proceedings of the 2nd

IEEE International Conference on Computer Science and Information

Technology, 8-11 August 2009. Beijing, China. 524-528.

Marcelino-Sádaba, S., Pérez-Ezcurdia A., Echeverría A., and Villanueva P (2014) Project risk

management methodology for small firms. International Journal of Project Management, 32 (2),

327–340. doi: 10.1016/j.ijproman.2013.05.009.

Öbrand, L., Nils-Petter, A., and Holmstr, J (2012) The Emergence of Information Infrastructure Risk

Management in IT Services. In: Proceedings of Hawaii International Conference on System

Sciences, 4-7 January 2012. Hawaii, USA. 4904-4913.

ORACLE (2013) ORACLE’s Primavera Risk Analysis. ORACLE. ORACLE.

http://www.oracle.com/us/products/applications/primavera/risk-analysis. Accessed 20 November

2013.

Pereira, A., Gonçalves, R., and Wangenheim, C (2013) Comparison of Open Source Tools for Project

Management. International Journal of Software Engineering and Knowledge Engineering, 23

(2), 189-209. doi: 10.1142/S0218194013500046.

Persson, J., Mathiassen, L., Boeg, J., Madsen, T., and Steinson, F (2009) Managing Risks in Distributed

Software Projects: An Integrative Framework. IEEE Transactions on Engineering Management,

56 (3), 508-532.

Project Management Institute – PMI (2013). A Guide to the Project Management Body of Knowledge. 5th

ed. Newtown Square: Project Management Institute, Inc..

Project Management Institute – PMI (2010) Study of Project Management Benchmarking - Brazil 2010.

PMI. www.pmsurvey.org. (in Portuguese). (accessed on 19 November 2013).

Raz, T., and Michael, E (2001). Use and benefits of tools for project risk management. International

Journal of Project Management, 19 (1), 9-17. doi: 10.1016/S0263-7863(99)00036-8.

SEBRAE. Criteria and concepts for enterprise classification. SEBRAE (in Portuguese).

http://arquivopdf.sebrae.com.br/uf/goias/indicadores-das-mpe/classificacao-empresarial.

(accessed on 19 November 2013).

SOFTEX Observatory (2012) Software and IT Services: The Brazilian Industry in Perspective. SOFTEX.

http://gvcepe.com/site/software-it-brazil-2012 (accessed on 19 November 2013).

Software Engeenering Institute – SEI (2010) CMMI for Development (CMMI-DEV) - Version 1.3.:

Carnegie Mellon University.

SOURCEFORGE. Dotmods: risks module. SOURCEFORGE.

http://sourceforge.net/projects/dotmods/files/Risks Module. Accessed 22 December 2013.

SOURCEFORGE. dotProject. SOURCEFORGE. http://sourceforge.net/projects/dotproject (Accessed on

17 March 2014).

Wangenheim, C., Wangenheim, A., and Hauck, J (2009) Enhancing Open Source Software in Alignment

with CMMI-DEV. IEEE Software, 26 (2), 59-67. doi: 10.1109/MS.2009.34.