See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/259122466

Risk management in software projects through Knowledge Management

techniques: Cases in Brazilian Incubated Technology-Based Firms

Article  in  International Journal of Project Management · January 2014

DOI: 10.1016/j.ijproman.2013.02.007

CITATIONS READS

39 632

5 authors, including:

Sandra Miranda Neves Carlos E S Silva

Universidade Federal de Itajubá (UNIFEI) Universidade Federal de Itajubá (UNIFEI)
20 PUBLICATIONS   78 CITATIONS    198 PUBLICATIONS   481 CITATIONS   

SEE PROFILE SEE PROFILE

Valerio Salomon Aneirson Francisco da Silva

São Paulo State University São Paulo State University
75 PUBLICATIONS   414 CITATIONS    32 PUBLICATIONS   168 CITATIONS   

SEE PROFILE SEE PROFILE

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

SISTEMA DE SUPORTE À DECISÃO COMBINADO A PEGADA HÍDRICA PARA À ANÁLISE DA SUSTENTABILIDADE EM REGIÃO SEMIÁRIDA View project

Lean Office View project

All content following this page was uploaded by Carlos E S Silva on 09 April 2018.

The user has requested enhancement of the downloaded file.

JPMA-01513; No of Pages 14

Available online at www.sciencedirect.com

International Journal of Project Management xx (2013) xxx – xxx

www.elsevier.com/locate/ijproman

Risk management in software projects through Knowledge Management

techniques: Cases in Brazilian Incubated Technology-Based Firms
Sandra Miranda Neves a, c,⁎, Carlos Eduardo Sanches da Silva b ,
Valério Antonio Pamplona Salomon c , Aneirson Francisco da Silva c ,
Bárbara Elizabeth Pereira Sotomonte b
a
UNIFEI, Federal University of Itajuba, Production Department, Irmã Ivone Drummond Street, 200, Industrial District, ZIP: 35903-087, Itabira, Minas Gerais State, Brazil
b
UNIFEI, Federal University of Itajuba, Production Engineering and Management Institute, BPS Ave., 1303, Pinheirinho, ZIP: 37.500-903, Itajuba, Minas Gerais State, Brazil
c
UNESP, Sao Paulo State University, Production Department, Ariberto Pereira da Cunha Ave., 333, ZIP: 12.516-410, Guaratingueta, Sao Paulo State, Brazil

Received 26 July 2012; received in revised form 3 January 2013; accepted 28 February 2013

Abstract

In businesses such as the software industry, which uses knowledge as a resource, activities are knowledge intensive, requiring constant adoption
of new technologies and practices. Another feature of this environment is that the industry is particularly susceptible to failure; with this in mind,
the objective of this research is to analyze the integration of Knowledge Management techniques into the activity of risk management as it applies
to software development projects of micro and small Brazilian incubated technology-based firms. Research methods chosen were the Multiple
Case Study. The main risk factor for managers and developers is that scope or goals are often unclear or misinterpreted. For risk management, firms
have found that Knowledge Management techniques of conversion “combination” would be the most applicable for use; however, those most
commonly used refer to the conversion mode as “internalization.”
© 2013 Elsevier Ltd. APM and IPMA. All rights reserved.

Keywords: Incubated Technology-Based Firms (ITBF); Software development; Risk management; Knowledge management

1. Introduction Despite the improvements already achieved, many software

Software projects are high-risk activities yielding variable
performance results (Charette, 2005). For Bannerman (2008),
software projects are complex endeavors in any context and are
particularly susceptible to failure. Corroborating these statements,
Rodriguez-Repiso et al. (2007) considers that the information
technology (IT) project management is a challenge even when the
measures necessary for its success are known and understood.
⁎ Corresponding author at: Federal University of Itajuba (UNIFEI), Production
Department, Irmã Ivone Drummond Street, 200, Industrial District, ZIP:
35903-087, Itabira, Minas Gerais State, Brazil. Tel./fax: +55 31 3834 3544.
E-mail addresses: sandraneves@unifei.edu.br (S.M. Neves),
sanches@unifei.edu.br (C.E.S. da Silva), salomon@feg.unesp.br
(V.A.P. Salomon), aneirson@yahoo.com.br (A.F. da Silva),
ad_barbara@yahoo.com.br (B.E.P. Sotomonte).
0263-7863/$36.00 © 2013 Elsevier Ltd. APM and IPMA. All rights reserved.
http://dx.doi.org/10.1016/j.ijproman.2013.02.007
development projects still use more resources than planned, take
longer to complete and provide less quality and functionality than
expected (Barros et al., 2004). But why do software projects fail
so often? For Charette (2005), among some of the most common
factors are: unrealistic goals; inaccurate estimates of necessary
resources; system requirements badly defined; poor presentation
of the project status; and risks not managed.
According to Dey et al. (2007), although some managers claim
that they manage risks in their projects, there is evidence that
they do not manage them systematically. The high failure rates
associated with projects of information systems suggests that
organizations need to improve not only their ability to identify, but
also to manage the risks associated with these projects (Jiang et al.,
2001). Neef (2005) complements saying that an organization
cannot effectively manage its risks if it does not manage its

Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
2 S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx

knowledge. For Cooper (2003), one of the most powerful tools in Fig. 1 shows a diagnosis result performed by Product
managing risk in projects is knowledge. Development Center of Technology-Based Incubator of
Such statements provide a useful link between risk manage- Itajubá (INCIT) in eight ITBF software projects in 2008 and
ment and knowledge management. Thus, it is intended to answer 2009. The results showed that the projects major part is carried
the following research question: How Knowledge Management out without the use of a formal methodology, this one being
techniques contribute to risk management in software develop- the main activity expected by the managers for the processes
ment projects? improvement (100%). Other expected activities were the
Based on the research question, this article aims at analyzing lessons learned structure (75%) and the projects risks analysis
the integration of Knowledge Management techniques to the (63%), both of them as a way to avoid working again and
activity of Risk Management in software development projects keeping up knowledge.
of micro and small Brazilian Incubated Technology-Based • Most importantly, the academic contribution: Gaps in
Firms (ITBF). It has as specific aims: (1) To analyze the main literature regarding theoretical and practical research on risk
risk factors in software development projects of ITBF; and management (Bannerman, 2008), related to project manage-
(2) To assess the techniques of Knowledge Management (KM) ment applied to small firms (Murphy and Ledwith, 2007;
as used by the ITBF in the management of the risk factors of White and Fortune, 2002); and Knowledge Management in
software development projects. the context of Risk Management approaches (as can be seen in
Justifications for research development make reference to Section 2.2).
the following statements:
The paper is structured as follows. Section 1 presents the
• Relevance of the theme: After performing a review of risks
research, its objectives and contributions; Section 2 states the
in the software development process, Bannerman (2008)
theoretical foundation of Risk Management applied to software
concluded that there is a need for better Risk Management,
development projects, approaches that address the theme of Risk
both in research and in practice. According to Wallace et al.
Management in software development, knowledge sharing and
(2004), “Unfortunately, despite these recommendations, there
transference and Knowledge Management techniques; Section 3
are relatively few tools available to help project managers to
defines the classification of the research and the planning of
identify and categorize risk factors in order to develop effective
the case study; Section 4 presents the form of data collection;
strategies.”
Section 5 analyzes the result; and finally, Section 6 presents
• Relevance of the objects of study: The objects of study are
discussion, conclusion and direction for future research.
software developers and managers of micro and small
ITBF. Dahlstrand (2007) defines a technology-based firm
as one that depends upon technology for its growth and
2. Literature review
survival; not necessarily meaning that the technology must
be new or innovative. For Radas and Bozic (2009), small
2.1. Risk Management in software development projects
and medium-sized firms are considered the engines of
economic growth, as well as job creation; and because
For Wallace et al. (2004), risks in software projects consists
of this importance, developed and developing countries are
of a number of factors or conditions that may represent a
interested in learning ways these firms carry out innova-
serious threat to the successful completion of the project. They
tions. The Serviço Brasileiro de Apoio às Micros e
imply quantifying the importance of such risks, assessing their
Pequenas Empresas—SEBRAE (2010) reports the, micro
frequency and their potential impact on project performance; as
and small firms responded, in 2010, by 99% of the total
well as in the development of strategies of control (Huang and
formal firms number, by 51.6% of private no-agricultural
Han, 2008). There are important studies relating to the various
formal employments and for almost 40% of the salary
risks of software development projects, and the foci of some of
mass. According to the similar survey, carried on in 2005,
this research are:
the lifting of closing rate of Brazilian firms, carried on
in the first quarter of 2004, showed that 49.9% of the firms
closed their activities after two years of existence, 56.4% • Mitigation of risks in software projects using methods of
after three years and 59.9% after four years. Opposed to this decision aid as the Analytic Network Process—ANP
aspect, the 2006 Panorama report by Associação Nacional de (Krishna Mohan et al., 2010).
Entidades promotoras de Empreendimentos de Tecnologias • Identification of risk factors (Bannerman, 2008; Costa et al.,
Avançadas - ANPROTEC (2006a, 2006b) showed a 2007; Han and Huang, 2007; Nakatsu and Iacovou, 2009).
closing rate of incubated firms of 20%. In five years, the • Structuring the framework for risk management (Dey et al.,
movement of the incubators grew by over 300%, being 2007) and how specific conditions impact risk perception
70% of the generated business by technological-based firms. and the decision to continue the projects (Du et al., 2007).
This information underlines the importance of incubators • Use of a risk checklist (Keil et al., 2008), a record of
related to the survival rate of micro and small firms, the software projects that were canceled, and the delivery results
importance of ITBF for the economical growth and the of those that have not been canceled (Emam and Koru,
development of surveys in this area. 2008).

Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
 S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx 3

Fig. 1. Identified Improvement opportunities at INCIT software firms.

• Models, approaches and structures for risk management in
software projects (McCaffery et al., 2010; Na et al., 2007;
Persson et al., 2009).
Fig. 2 shows the co-citation analysis of the main articles
evaluated. For Marshakova (1981), co-citation measures the
degree of integration between two or more articles, and the
number of documents where those papers are cited simultaneously.
There can be observed a consensus of all the authors to
Boehm's, 1991 article and the existence of a relationship
among the others. Within the context of the pieces of research
described, it is recognized as a tendency in the identification of
risk factors (Fig. 3).
In this sense, Schmidt et al. (2001) defines risk factors as “a
condition in which may be present a serious threat to the
complete success of a software development project.”
Regarding the object of the study in the research, it was
mostly about public and private firms of large-scale research
institutes, such as the Project Management Institute (PMI). This
indicates that research directed to micro and small enterprises

Fig. 2. Co-citation analysis of the main articles.

Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
4 S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx

Fig. 3. Distribution of publications by focus.

or incubated technology-based firms constitute a gap in the
knowledge base; thus, it is the focus of this study.
2.2. Approaches to managing risks in software projects
The process of identifying and estimating risks of systems can
be accomplished by a variety of techniques and approaches.
Among the techniques are cited: Regression Analysis; Expert
Systems and Stochastic Models (Houston et al., 2001); Influence
Diagram; Monte Carlo Simulation; Program Evaluation and
Review Technique (PERT); Sensitivity Analysis; Analytic
Hierarchy Process (AHP); Fuzzy Set Approach (FSA); Neural
Networks; Decision Tree and Fault Tree Analysis; Risk
Checklist; Risk Map; Diagram of Cause and Effect; Delphi
Technique; Combination of Decision Tree; and AHP (Dey and
Ogunlana, 2004). The above techniques are applied as part of
Risk Management and will not be covered in this research.
Concerning the approaches, Table 1 presents a comparison of
the main approaches regarding Risk Management in software
projects.
The approaches presented are very similar in content. Some
provide a more detailed description of the steps, such as Project
Management Body of Knowledge—PMBOK (PMI, 2008) and
Capability Maturity Model Integration—CMMI (SEI, 2006);
however, for those that do not provide this detail when
evaluating the content, it is clear that constant steps are implicit
in other approaches.
The greatest distortions among the approaches studied are
included in the steps of learning and communicating risks, which
may be an indication of the importance of pursuing elements
of work, which include Knowledge Management in the Risk
Management process endemic within software development
environments; or even that Knowledge Management plays an
integral part in the approach to project management.

Table 1
Comparative approaches to managing risks in software projects.
Steps Boehm ISO/IEC 15.504 MSF RUP ISO 10006 AS/NZS 4360 CMMI MPS.BR PMBoK
(1988) (1999) (2002) (2003) (2003) (2004) (SEI, 2006) (SOFTEX, 2006) (PMI, 2008)
Plan the management X X X X X X
Identify X X X X X X X X X
Prepare qualitative analysis X X X X X X X X X
Prepare quantitative analysis X X X X X X X X X
Plan responses X X X X X X X X X
Solve X X X X X X X X X
Monitor and control X X X X X X Implicit X X
Report Implicit Implicit X Implicit Implicit
Learn X Implicit Implicit Implicit Implicit

Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
 S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx
2.3. Knowledge sharing and transference
Anantatmula and Kanungo (2010, p. 100) state that
“knowledge is recognized as a critical resource to get and
keep up a competitive advantage in business”. So several firms
expect that KM, once accomplished in a proper way, may
transform knowledge into a competitive advantage (Fan et al.,
2009). For Davenport and Prusak (1998), KM is composed of
the set of processes that seek to support the organizational
environment in the generation of knowledge, its registration
and its transference. Still according to those authors, knowledge
codification and coordination is made up of having the
organizational knowledge available to those who need it. For
Rahman (2011, p. 213) “creating a knowledge sharing environ-
ment in an organization requires changes in the corporate culture.
The knowledge sharing culture needs to be seen as a positive
force towards creating an innovative organization, especially
through the element of reciprocity”. In the projects management
context this function is assigned to the Project Management
Office (PMO), which takes over, this way, the important role of
transferring and sharing the organizational knowledge, especially
the knowledge related to lessons learned in previous projects and
the risks related to them. According to Pemsel and Wiewiora
(2013) from a knowledge creation and sharing perspectives,
there has been limited research concerning the implications
of Project Managers learning behaviors and their preference
to learn, share and integrate knowledge in relation to PMO
functions and activities. Among the PMO roles and responsibil-
ities we underline the shared resources Management in all the
projects administered by the PMO; Methodology identification
and development, better practices and project management
patterns; Guidance, advising, training and supervision and the
communication coordination among the projects (PMI, 2008).
The project manager takes care of the constraints (scope,
schedule, cost and quality, etc.) of each project, while PMO
takes care of methodologies, patterns, the global risk/opportunity
and the project interdependence at the firm (PMI, 2008).
Considering the reality of micro and small ITBF, firms this size
normally don't have a PMO, although its main functions
normally informally exist. One underlines those evidences that
were identified in Aerts et al. (2007, p. 20), who claim that
incubators accomplish the main PMO functions, once ITBF don't
have a PMO, being small-sized and neophytes.
2.4. Knowledge Management techniques
For Nonaka and Takeuchi (1995) the creation of knowledge
follows through interactions of information and its effective
transformation occurs in four modes of conversion: socialization;
externalization; combination; and internalization. The mode of
knowledge conversion called the SECI model, was associated
with KM techniques presented as follows:
• Socialization: conversion of tacit knowledge to tacit. It is the
process of sharing knowledge and experiences. To this mode
of conversion were associated KM techniques of communities
of practice, multidisciplinary teams, brainstorming, customer
Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
5
interactions, observation, imitation and practice, and database
skills.
• Externalization: conversion of tacit knowledge to explicit. To
this mode of conversion were associated the KM techniques of
narrative and oral histories, metaphors, analogies, concepts,
hypotheses or models and knowledge repositories.
• Combination: conversion of explicit knowledge to explicit. It is
the systematization of concepts. To this mode of conversion
were associated the KM techniques of formal meetings,
telephone conversations, computerized communication net-
works, scenario, simulation, prototyping, and formal education.
• Internalization: Incorporation of explicit knowledge to tacit
knowledge. The KM technique of learning by doing is
associated with this mode of conversion.
3. Classification of the research
The research method used was a multiple case study (Bryman
and Bell, 2007; Eisenhardt, 1989; Yin, 2009), for the purpose of
exploration (Yin, 2009). The methods used for data collection
were the questionnaire, observation, semi-structured interviews
and document analysis.
The following propositions were established:
Proposition 1. Managers and developers of the evaluated
ITBF have the same perception regarding major risk factors
for software development projects.
Proposition 2. Managers and developers of the evaluated
ITBF have the same perception regarding KM techniques,
which are more applicable to the management of risk factors in
software development projects.
3.1. Planning of the case study
The criteria used in this study to select the object firms were:
area of operation (software development); representativity for
the region where they are inserted; and to be prominent firms in
incubators in which they participate. The firms selected were
four micro and small incubated software development busi-
nesses within the state of Minas Gerais, Brazil. They received
several national and regional awards, and have been featured in
prominent magazines. The drafting of the questionnaire for data
collection progressed in three stages:
• For the selection of risk factors to be considered in the
questionnaire, we used the AHP method. According to Saaty
(1990), the use of AHP for decision-making is in theory a
relative measure based on comparison of pairs to get tables of
normalized absolute numbers, the elements of which, are
afterwards used as priorities. The selection was made by 10
experts (two managers of incubators, three academics, and
five managers of incubated firms). Among the approaches
considered (Baccarini et al., 2004; PMI, 2008; Ropponen and
Lyytinen, 2000; Schmidt et al., 2001; SEI, 2006; Wallace et
al., 2004), the approach proposed by Schmidt et al. (2001) was
viewed as the most suitable considering an environment for
6 S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx

Table 2
General information from the firms evaluated.
Number of employees
Company A Company B Company C Company D Mean Standard deviation
12 28 25 6 17.75 9.07

Incubation time/post-incubation (years)

Company A Company B Company C Company D Mean Standard deviation
8.3 4.2 3.2 1.3 4.25 2.56

Last completed course

Doctorate Master's degree Specialization Complete higher degree Incomplete higher degree High school
– 1 1 7 6 –

Age (years)
Up to 24 From 25 to 34 From 35 to 44 From 45 to 54 Over 55
7 8 – – –

Average duration of projects

Up to 1 month From 1 to 12 months From 12 to 24 months From 24 to 36 months Over 36 months
3 (20%) 9 (60%) 3 (20%) – –

Position held Gender

Director/management Developers Male Female
9 (60%) 6 (40%) 14 (93%) 1 (7%)

micro and small ITBF. The risk factors proposed by Schmidt The following sequence for data collection was used: securing
et al. (2001) were used to assess the respondents on a scale of 1 approval from top management to conduct the research;
to 5, the probability of risk occurring, and the impact of such informing the managers of the firms about the mutual benefits
risks should they occur. of the study, with specific reports having been sent to each
• In the second stage, for each risk factor proposed by Schmidt company; convening meetings with managers and software
et al. (2001), KM techniques listed in Section 2.4 were developers; document analysis, consisting of portfolios of the
introduced which allowed respondents to determine which company and its customers, including work procedures and
KM techniques could best facilitate the analysis of the knowledge repositories; implementing the search questionnaire;
proposed risk factors; in addition to identifying those and conducting the interviews. During this phase the perceptions
techniques associated with modes of knowledge conversion of the respondents and the researchers were recorded in order not
proposed by Nonaka and Takeuchi (1995) according to
Appendix A.
• The third stage referred to collecting general information
about the firms and respondents. Table 3
Ranking of the major risk factors according to managers and developers.
The pilot test was conducted in two of the Brazilian incubated Question Risk factors Mean
firms from Technology-Based Incubator of Montes Claros 13 Scope or goals are often unclear or 6.70
Educational Foundation (INCET). The two firms stood out in misinterpreted (5.1)
their area of expertise due to activities related to software projects 14 Change of scope/goals (5.2) 6.26
10 Lack of an effective methodology for 5.97
and because they presented different times of incubation. The
managing projects (4.3)
pilot test resulted in proactive improvements in the research 26 Volatility of the personnel involved (11.2) 5.89
questionnaire and the inclusion of the failure to obtain financing 20 Deadlines and execution times of tasks 5.78
and high taxes as two new risk factors. poorly estimated (8.1)
7 Lack of cooperation from users (3.3) 5.75
8 Inadequate management of change (4.1) 5.73
4. Data collection 16 Constant changes in the requirements (6.1) 5.66
3 Failure to obtain user commitment by the 5.60
Data were collected during the months of December, 2009, project manager (2.3)
and January, February and March of 2010, totaling fifteen 1 Change in ownership of the product or the 5.56
senior manager of the project (1.5)
respondents (nine managers and six software developers).

Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
 S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx 7

to lose important information for further analysis; also, in this

stage of data collection, confidentiality was formally assumed.
The effectiveness of the researcher had its greatest limitations
while implementing the questionnaire by using annexes with
detailed descriptions of the significance of each risk factor, KM
techniques, as well as examples. Respondents were asked to
check those definitions to help eliminate any doubt, should it
arise in understanding the issues. A consideration for each case
was the notation, proposed by Eisenhardt (1989) on “How does
this case differ from the last one?”. This allowed for comparisons
among the firms examined. Table 2 presents the general
information obtained.
Fig. 4. Cluster analysis for risk factors.
5. Analysis of the results

The data were analyzed according to the specific objectives

set, as follows.
an established pattern, a fact proven though the development
procedure analysis. This risk factor boosts the surveys
5.1. Analysis of the major risk factor
conducted at ITBF (Fig. 1), where 100% of the evaluated
firms considered as an opportunity of a systematic improve-
Table 3 lists the top ten risks factors, according to their
ment and implementation for project management and 63% of a
average probability of occurrence and impact for managers and
risk analysis system.
developers.
The technique of cluster analysis was used to evaluate the
The reliability of the questionnaire was calculated after
data generated by Table 3. For Everitt (1993) groups formed
considering the degree of homogeneity of the set of responses
in this analysis are similar to each other internally because
by Cronbach's alpha, which provides internal consistency values.
the variance within the cluster is minimal; and they have
Although there is no absolute standard, Cronbach's alpha values
differences related to other groups because the variance
equal to or greater than 0.70 reflect an acceptable reliability (Hair
between is maximal. A similarity level of 34% was obtained
et al., 1998; Nunnally and Bernstein, 1994). For this analysis we
as a result the dendogram presented in Fig. 4.
obtained a Cronbach's alpha of 0.933, indicating high consisten-
The group formed proved to be relatively homogeneous,
cy. The geometric mean was used to rank the data.
which allowed for a classification into three categories: high
The main risk factor for managers and developers (scope or
risk, moderate risk and low risk (Table 4), a description of the
goals are often unclear or misinterpreted) has been assessed
issues can be seen in Appendix A.
through research protocol, also being checked through an
Further analysis of the data obtained in the survey is
interview. Managers, as well as developers, considered the fact
presented:
of not clearly defining the project scope or goals can generate a
series of tasks. These tasks can cause wear and financial losses
for the firm. The second risk factor, “Change of scope/goals” • Regarding the level of awareness of those interviewed for
is present as a consequence of the first one and reaffirms Risk Management, the majority was high (47%). However,
its importance. It also matches with Emam and Koru (2008) 87% of respondents reported not having formal training in
researches, according to them scope and requirements are the the necessary methodology.
main reasons for the project cancelation. It was noticed that the • With respect to which approach to Risk Management would
third risk factor (lack of an effective methodology for managing be implemented at the company, most of them still prefer
projects) was one of the most issues commented by the methods as a matrix of risks and approaches as proposed by
developers, who fell much more comfortable when they follow PMBOK.

Table 4
Result of cluster analysis for risks factors.
Cluster Groups formed Questions Mean General
Probability Impact
1 High risks Q01, Q05, Q20, Q03, Q26, Q08, Q06, Q07, Q17, Q10, 1.929 3.585 5.514
Q16, Q13, Q14, Q12, Q21, Q28, Q23, Q24
2 Moderate risks Q02, Q27, Q09, Q22, Q18, Q11, Q29, Q25, Q19, Q15 1.730 2.986 4.716
3 Low risks Q04, Q30, Q31 1.580 1.769 3.348

Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
8 S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx

Table 5
Mann–Whitney test result.
Risk factor Managers Developers P-value
Requirements misinterpreted and/or poorly defined in the early development 7.000 4.500 0.0471
Poorly estimated costs 7.000 2.000 0.0054
Staff involved insufficiently/inadequately 6.000 2.000 0.0100

• The main risk factor identified for managers and developers
(scope or goals are unclear or misunderstood) identified
through the research questionnaire (Table 3), was also found
through interviews and document analysis.
• It was noted that the third risk factor (lack of an effective
methodology for managing projects) was one of the most
commented upon by the developers, who feel more comfort-
able when following a set pattern.
• The risk “volatility of the personnel involved” appeared to
be a characteristic of micro and small ITBF, often
mentioned by managers during the interviews. In ITBF
there is a concentration of software development interns
whom, according to the managers, as soon as they find
new opportunities they leave the company, causing a high
turnover of staff and loss of knowledge.
• Assessing the major risk factors for managers and software
developers separately, it has been determined that the main
risk factor for the managers is “the badly estimated task
execution deadlines” associated with Cronbach's alpha of
0.909; ranking second among the 10 major risk factors for
software projects by Boehm (1991).
• For developers, the main risk was “Scope or goals are often
unclear or misinterpreted” with Cronbach's alpha of 0.923. By
means of interviews and documentary analysis, it was noted
that two factors may be associated with the characteristic of
each job: deadlines, most of the time, are estimated by
managers and are essential to a successful project, especially
considering the dynamic of the software sector; and clear
scope and objectives, on the other hand, are needed by
developers for correct execution of their activities.
The nonparametric Mann–Whitney test was used to evaluate
Proposition 1 that the managers and developers of the ITBF
evaluated have the same perception in relation to major risk
factors for software development projects. The Mann–Whitney
test is used to assess the variables of two independent samples
derived from the same population (Mann and Whitney, 1947).
Table 5 presents the risk factors with significant differences
(b 0.05).
Mann–Whitney's test indicated that only the “Requirements
misinterpreted and/or poorly defined in the early development”
risk factors, “poorly estimated costs” and “Staff involved
insufficiently/inadequately” showed statistically significant
differences among managers and developers; for the other
issues the perceptions were at the same level. A possible
explanation for the three identified differences are due to the
fact that, most of the time, the managers are the ones interacting
with clients for a definition of the product main requirements
and they are also the ones defining the involved costs. As to the
“Staff involved insufficiently/inadequately” factor, it has been
noticed that the developers noticed more the “insufficient”,
once the major part thought they work with a smaller number of
collaborators than the required for the projects. For the next
surveys it would be interesting to take into consideration these
two items (insufficient and inadequate) separately. Taking into
account the total of 31 questions and a significant level of 5%,
Proposition 1 is therefore accepted.
The data regarding the main risk factors for managers
were compared to the results obtained by Schmidt et al. (2001)
which used the Delphi method to conduct a survey in three
countries with different socioeconomic backgrounds: Hong Kong

Table 6
Ranking reduced risk factors for managers compared to other studies.
Risk factor Ranking of the Schmidt–HKG, USA e Schmidt–HKG Schmidt–USA Schmidt–FIN
research (2010) FIN (2001) (2001) (2001) (2001)
Badly estimated task execution deadlines 1 – – – 7
Scope or goals are often unclear or misinterpreted 2 – – 9 –
Change of scope/goals 3 7 5 10 19
Poorly estimated costs 4 – – – 18
Requirements misinterpreted and/or poorly defined 5 2 7 2 6
in the early development
Lack of knowledge/skills of the project team 6 5 13 11 3
Change in ownership of the product or the senior 7 – 5 – –
project manager
No planning or inadequate planning 8 – – – 5
Constant changes in requirements 9 6 8 14 9
Staff involved insufficiently/inadequately 10 10 15 13 15
Lack of skills for project management 11 – – 5 1

Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
 S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx 9

Table 7
KM techniques used by firms.
KM techniques Number of Percentage Conversion
citations mode
Meetings (face-to-face) 13 12% Combination
Learn by doing 13 12% Internalization
Training at work 11 10% Socialization
Brainstorming 10 9% Socialization
Customer interactions 9 8% Socialization
Knowledge repositories 8 7% Externalization
Formal education 8 7% Combination
Observation, imitation and practice 7 6% Socialization
Scenarios, simulation and prototyping 7 6% Combination
Telephone conversations and 6 5% Combination
computer network
Database skills 6 5% Socialization
Multidisciplinary teams 5 4% Socialization
Communities of practice 4 4% Socialization
Narratives and oral stories 3 3% Externalization
Metaphors, analogies, concepts, 3 3% Externalization
Fig. 5. Percentual of KM techniques currently used for risk management.
hypotheses
Total 113 100%

(HKG—eleven respondents), Finland (FIN—thirteen respon-
dents) and the United States (USA—twenty-one respondents).
This research differs from the work of Schmidt et al. (2001) with
regard to the method and the object of study; however, the results
obtained allowed us to make the comparison for exploratory
purposes (Table 6).
Considering the eleven major risks identified by Schmidt et
al. (2001), only five fit within the risks identified in this study,
with only the risk, “Staff involved insufficiently/inadequately,”
holding the same position (10° in the rankings). The main risk
factor identified by some authors (e.g. Nakatsu and Iacovou,
2009; Schmidt et al., 2001) was “lack of commitment of top
management to the project,” has been considered as one of the
last conducted survey (placed 24th in the ranking). A possible
explanation is due to the fact that at a small firm the project
manager is, most of the time, the owner, once it may happen
the current project is the only one product, generating effort
concentration in its production. It has been realized the
existence of a consensus among the managers and developers
that this kind of risk is not common at ITBF. This step

Table 8
KM techniques for the management of risk factors.
KM techniques Number of Percentage Conversion
citations mode
Meetings (face-to-face) 264 18% Combination
Training at work 146 10% Socialization
Customer interactions 133 9% Socialization
Telephone conversations and 116 8% Combination
computer network
Brainstorming 109 7% Socialization
Formal education 94 6% Combination
Multidisciplinary teams 93 6% Socialization
Communities of practice 83 6% Socialization
Knowledge repositories 79 5% Externalization
Scenarios, simulation and 72 5% Combination
prototyping
Database skills 69 5% Socialization
Learn by doing 69 5% Internalization
Observation, imitation and 50 3% Socialization
practice
Metaphors, analogies, concepts, 46 3% Externalization
hypotheses
Narratives and oral stories 35 2% Externalization
Total 1458 100%
Fig. 6. Percentual of KM techniques more applicable to risk management.

Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
10 S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx

Table 9 be most suitable for management of risk factors, according to

Result of the Mann–Whitney test for the perception of KM techniques. Table 8. The percentages were calculated using the weighted
KM techniques Median average, since some modes of conversion have a higher number,
Managers Developers P-Value e.g. socialization.
Training at work 9.00 11.50 0.5169 The main findings for this analysis are presented in the
Communities of practice 4.00 5.50 0.3768 following sequence:
Multidisciplinary teams 4.00 4.50 0.8597
Brainstorming 3.00 6.5 0.5557 • It can be seen in Fig. 5 that the conversion mode in use today
Customer interactions 7.00 11.00 0.6374
by firms to analyze their risks is internalization (39%) using
Observation, imitation and practice 1.00 2.50 0.1753
Narratives and oral stories 1.00 2.00 0.4795 KM techniques and “learning by doing” (Table 7).
Metaphors, analogies, concepts, hypotheses 1.00 2.50 0.5169 • However, according to Fig. 6, the respondents clearly
Knowledge repositories 3.00 4.00 0.4437 considered the most applicable conversion mode for the
Meetings (face-to-face) 20.00 11.00 0.0392 management of risk factors would, for the most part, be the
Telephone conversations and computer 7.00 4.00 0.3768
combination mode (38%); specifically, KM techniques such
network
Scenarios, simulation and prototyping 3.00 5.00 0.5169 as meetings and the use of computerized networks (Table 8).
Formal education 7.00 4.5 0.4094 The technique of “meetings—face-to-face” is still the most
Database skills 4.00 3.00 0.7237 commonly cited, though the technique of “training at work”
Learn by doing 2.00 5.00 0.0990 is second, displacing “learning by doing,” which is relegated
to last. This suggests that firms studied should review the
use of KM techniques proportionally to analyze their risks,
as well as the assessment as to which techniques are indeed
completed the first specific objective, which was to analyze the applicable to each risk factor identified.
main risk factors in ITBF software development projects.
Mann–Whitney was used to test Proposition 2 that the
managers and developers of the ITBF evaluated are in congruence
5.2. KM techniques used in the analysis of risk factors regarding KM techniques most applicable to the management of
the risk factors in software development projects (Table 9).
Table 7 presents the main KM techniques used by the It is notable that the only KM technique with a significant
evaluated firms considering the conversion of knowledge difference (b 0.05) was “meetings—face-to-face” (P-value
method proposed by Nonaka and Takeuchi (1995) according 0.0392), having been cited more by managers than by
to Section 2.4. developers. The perceptions for the remaining questions were
Table 8 contains a list of the primary KM techniques used by equivalent; therefore, considering a total of 15 questions and a
the surveyed firms that should be employed for the management significance level of 5%, Proposition 2 is therefore accepted.
of risk factors identified in software development projects. The The “work training” technique was the most cited by the
Cronbach's alpha for this analysis was 0.956, indicating high developers than by the managers, which can indicate the need
internal consistency. for improvements related to this practice. Completing this step
As for KM, 67% of respondents conceded that they did not met the second specific aim, which was to evaluate KM
have formal training in the methodology for conducting activities techniques used by the ITBF in the management of risk factors
in this area; nevertheless, they use the same techniques. Fig. 5 for software development projects.
shows the percentage of KM techniques currently used by After presenting discussions and conclusions concerning the
firms rated according to the SECI model proposed by Nonaka development of this work, this paper will close with a list of
and Takeuchi (1995) as presented in Table 7. Fig. 6 shows the techniques cited by respondents as the most suitable for
the percentage of KM techniques that respondents consider to the management of the major risk factors, considering only the

Table 10
Most frequently cited KM techniques for analyzing major risks.
Risk factors Most frequently cited KM techniques/number of citations
Scope or objectives are unclear or misunderstood Meetings (12), customer interactions (9), telephone conversations
and Computer networking (7)
Change of scope/objectives Meetings (13), customer interactions (8), brainstorming (5)
Lack of an effective methodology for managing projects Training at work (9), formal education (7), knowledge repositories (5)
Volatility of the personnel involved Training at work (6), phone conversations and computer networking (6),
database skills (5), meetings (5), and knowledge repositories (5)
Deadlines and execution times of tasks poorly estimated Meetings (11), training at work (5), multidisciplinary teams (5),
knowledge repositories (5)

Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
 S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx
top five risk factors identified by managers and developers
(Table 10).
As for “Scope or goals are often unclear or misinterpreted” risk
factor, the meetings would aim to confirm the scope understanding.
The interactions with clients would aim the closing and following
up of specifications, minimizing or eliminating, this way, possible
mistakes in the project development.
6. Discussions and conclusions
To encourage existing innovation in the assessed ITBF,
knowledge is essential to carry out activities in these firms;
however, much of this knowledge is still in the realm of
tacit knowledge (experience), embedded initial efforts for the
purpose of storing this knowledge for use in Risk Management.
Firms with longer incubation, or firms already graduated,
demonstrated more initiative regarding dissemination, use and
retention of knowledge and Risk Management. This finding
suggests that risk assessment also depends on lessons learned
conducting the projects.
It was found that the probability of risks obtained in all cases
has lower averages than the impact of risks on a case-by-case
basis. This may indicate that due to the life cycle in which some
respondent firms operate, some still lack the necessary
experience to perform such evaluation; possibly due to lack of
historical data or that the knowledge generated in other reviews
has not even been shared.
As a general analysis, the managers as well the de-
velopers, at the evaluated firms, have similar perceptions
related to the main risk factor for the software development
projects and the most suitable KM techniques for the risk
factor analysis. It has been noticed that, during the
interviews, meetings and visits, these firms employ a small
number of teams, apparently cohesive and motivated, with
good educational level, which shows that they can visualize
with greater ease the firm particularities, a fact that can be
wisely used by the managers.
The transference of knowledge in order to manage risk does
not seem to be endemic to the culture of the firms evaluated;
thus, the identification of risk is still more reactive than
preventive. The fact that ITBF have easier access to financing
may contribute to the delay of the analysis, encouraging the
strategy of transferring risk to the agencies. For firms that
performed Risk Management, even in its initial stage, there was
a tendency, in relation to the control steps, to increase their
efforts in the planning stages. Motivation for this tendency may
be to meet customer requests or the demands of regulators.
Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
11
In response to the research question, it was found that the
contribution of KM techniques for the activity of risk manage-
ment in software development projects of small and micro ITBF
occurred at the time those techniques were used in order to lead to
risk identification, analysis and prioritization; however, in order
that those initiatives achieve the desired effect, they should be
structured with consideration to the particularities of each
company and to the use of their applied techniques.
The initiation of the discussion on the integration of KM
techniques of risk management in micro and small ITBF is
considered to be the most significant contribution of this work
to the knowledge base, which had not been addressed in other
studies on the subject. It is also of particular note the following
research findings: identification of risks according to the
perceptions of managers and developers; the selection of a list
of specific risk factors for the environment of micro and small
incubated software development firms; the ratio of KM
techniques more applicable to the management of the main
risks identified.
The main limitations of such a task refer to the survey
universe, once the study has been carried out at micro and small
ITBF, not being generalized for all the firms. As to the
approach, this survey embroidered the risk factors identification
and analysis, not taking into consideration the identified risk
treatment. Positive risks have not been taken into consideration
either, that is, the opportunities, which are the events or facts
positively affecting the project goals, but only the negative
ones, not aiming to exhaust them, once they are dynamic. Such
a survey puts under the spot the software risk project, not the
risk of the product itself, during its development and after its
release.
For future work, the following is suggested: the identifica-
tion of risks according to the life cycle of the incubated firms;
research demonstrating the real benefits of applying risk
management in ITBF; ways of dealing with identified risks
given the reality of these firms; development of a system that
helps managers of micro and small ITBF with the implemen-
tation of risk management; the use of existing methodologies, or
adaptations thereof, as a basis; and effectively using research
developed KM techniques.
Acknowledgments
The authors need to express their acknowledgments to
two Brazilian research agencies: the CAPES Foundation (Grant
No. PE024/2008) and FAPEMIG (Grant No. PPM-00586), and
especially all interviewees and reviewers.
12 S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx

Appendix A

Table A1
Questionnaire used in the survey.

Techniques

13-Scenarios, simulation and

6-Observation, imitation and

8-Narratives and oral stories

conversations and computer

10-knowledge repositories
2-Communities of practice
3-Multidisciplinary teams

12-Documents, telephone
5-Customer interactions

9-Metaphors, analogies,
concepts, hypotheses

14-Formal education
1-Training at work

15-Learn by doing
16. Not applicable
7-Database skills
4-Brainstorming

11-Meetings

prototyping
network
practice
Risk Factors

Q01 Change in ownership of the

product or the senior
manager of the project (1.5)
Q02 lack of commitment of top
management to the project
(2.1)
Q03 Failure to
obtain user commitment by
the project manager (2.3)
Q04 Conflicts between user
departments (2.4)
Q05 Failure to manage expectations
of end users (3.1)
Q06 Lack
of adequate user involvement
(3.2)
Q07 Lack of cooperation
from users (3.3)
Q08 Inadequate management of
change (4.1)
Q09 Lack of skills for effective
management of the
project (4.2)
Q10 Lack of effective methods for
project management (4.3)
Q11 Improper definition of roles
and responsibilities (4.4)
Q12 Inadequate or
nonexistent control (4.5)
Q13 Scope or goals are often
unclear or misinterpreted (5.1)
Q14 Change of scope / goals (5.2)
Q15 Number of
client's organizational
units involved (5.5)
Q16 Constant changes in the
requirements (6.1)
Q17 Requirements misinterpreted
and/or poorly defined in the
early development (6.2)
Q18 New or unfamiliar subject
matter for both users and
for developers (6.3)
Q19 Poorly estimated costs (7.3)
Q20 Badly estimated task execution
deadlines (8.1)

Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
 S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx 13

Table A1 (continued)

Techniques

13-Scenarios, simulation and

6-Observation, imitation and

8-Narratives and oral stories

conversations and computer

2-Communities of practice
3-Multi disciplinary teams

10-knowledgerepositories

12-Documents, telephone
5-Customer interactions

9-Metaphors, analogies,
concepts, hypotheses

14-Formal education
1-Training at work

15-Learn by doing
16. Not applicable
4-Brain storming

7-Database skills

11-Meetings

prototyping
network
practice
Risk Factors

Q21 Lack of effective methodology

or process development (9.1)
Q22 Attempt to
adopt new development
method/ technology during the
project (9.2)
Q23 Lack of knowledge /skills of
the project team (10.1)
Q24 Lack of interpersonal skills of
managers in leading the project
team (10.2)
Q25 Staff involved insufficiently/
inadequately (11.1)
Q26 V olatility of the staff involved
(11.2)
Q27 Introduction of
new technologies (12.1)
Q28 Complicated dependencies on
projects from multiple
vendors, integration of
technologies from various
sources (13.2)
Q29 No planning or inadequate
planning (14.1)
Q30 Failure to
obtain financing (15.1)
Q31 High taxes (15.2)
Mark with an X the techniques of
knowledge management that are
used in your company aiming
the risk management in projects.

References Baccarini, D., Salm, G., Love, P.E.D., 2004. Management of risks in
information technology projects. Industrial Management and Data System
Aerts, K., Matthyssens, P., Vandendempt, K., 2007. Critical role and screening 104 (4), 286–295.
practices of European business incubators. Technovation 27 (5), 254–267. Bannerman, P.L., 2008. Risk and risk management in software
Anantatmula, V.S., Kanungo, S., 2010. Modeling enablers for successful KM projects: a reassessment. Journal of Systems and Software 81
implementation. Journal of Knowledge Management 14 (1), 100–113. (12), 2118–2133 .
ANPROTEC—Associação Nacional de Entidades Promotoras de Empreendimentos Barros, M.O., Werner, C.M.L., Travassos, G.H., 2004. Supporting risks in software
de Tecnologias Avançadas, 2006a. Número de incubadoras em operação no project management. Journal of Systems and Software 70 (1–2), 21–35.
Brasil. Available in: http://www.anprotec.org.br (Accessed 27 mai. 2009). Boehm, B.W., 1988. A spiral model of software development and enhancement.
ANPROTEC—Associação Nacional de Entidades Promotoras de Empreendimentos IEEE Computer 21 (5), 61–72.
de Tecnologias Avançadas, 2006b. Estudo, análise e proposições sobre as Boehm, B.W., 1991. Software risk management: principles and practices. IEEE
incubadoras de empresas no Brasil – Relatório Técnico. Available in: Software 8 (1), 32–41.
http://www.anprotec.org.br (Accessed 27 dez. 2012). Bryman, A., Bell, E., 2007. Business Research Methods, 2nd ed. Oxford
AS/NZS 4360, 2004. Standards Australia and standards New Zealand. Risk University Press, New York.
Management. Sydney, NSW.0 7337 5904 1. Charette, R.N., 2005. Why software fails. IEEE Spectrum 42 (9), 42–49.

Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
14 S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx
Cooper, L.P., 2003. A research agenda to reduce risk in new product
development through knowledge management: a practitioner perspective.
Journal of Engineering and Technology Management 20 (1–2), 117–140.
Costa, H., Barros, M.O., Travassos, G.H., 2007. Evaluating software project
portfolio risks. Journal of Systems and Software 80 (1), 16–31.
Dahlstrand, A.L., 2007. Technology-based entrepreneurship and regional develop-
ment: the case of Sweden. European Business Review 19 (5), 373–386.
Davenport, T.H., Prusak, L., 1998. Working Knowledge: How Organizations
Manage What They Know. Harvard Business School Press.
Dey, P.K., Ogunlana, S.O., 2004. Selection and application of risk management
tools and techniques for build-operate-transfer projects. Industrial Management
e Data Systems 104 (4), 334–346.
Dey, P.K., Kinch, J., Ogunlana, S.O., 2007. Managing risk in software
development projects: a case study. Industrial Management e Data Systems
107 (2), 284–303.
Du, S., Keil, M., Mathiassen, L., Shen, Y., Tiwana, A., 2007. Attention-shaping
tools, expertise, and perceived control in IT project risk assessment.
Decision Support Systems 43 (1), 269–283.
Eisenhardt, K.M., 1989. Building theories from case study research. Academy
of Management 14 (4), 532–550.
Emam, K.E., Koru, A.G., 2008. A replicated survey of IT software project
failures. IEEE Software 25 (5), 84–90.
Everitt, B.S., 1993. Cluster Analysis. Hodder & Stoughton, London.
Fan, Z.-P., Feng, B., Sun, Y.-H., Ou, W., 2009. Evaluating knowledge
management capability of organizations: a fuzzy linguistic method. Expert
Systems with Applications 36 (2), 3346–3354.
Hair, J.F., Anderson, R.E., Tatham, R.L., Black, W.C., 1998. Multivariate Data
Analysis, 5th ed. Prentice Hall, Upper Saddle River, NJ.
Han, W.-M., Huang, S.-J., 2007. An empirical analysis of risk components and
performance on software projects. Journal of Systems and Software 80 (1),
42–50.
Houston, D., Mackulak, G., Collofello, J., 2001. Stochastic simulation of risk
factor potential effects for software development risk management. Journal
of Systems and Software 59 (3), 247–257.
Huang, S.-J., Han, W.-M., 2008. Exploring the relationship between software
project duration and risk exposure: a cluster analysis. Information
Management 45 (3), 175–182.
ISO/IEC 15.504-5, 1999. Information Technology—Software Process Assess-
ment—Part 5: An Assessment Model and Indicator Guidance. International
Standard Organization.
ISO—International Organization for Standardization, 2003. ISO 10.006:2003—
Quality Management Systems—Guidelines for Quality Management in
Projects. International Standard Organization.
Jiang, J.J., Klein, G., Discenza, R., 2001. Information system success as
impacted by risks and development strategies IEEE. Transactions on
Engineering Management 48 (1), 46–55.
Keil, M., Li, L., Mathiassen, L., Zheng, G., 2008. The influence of checklists
and roles on software practitioner risk perception and decision-making.
Journal of Systems and Software 81 (6), 908–919.
Krishna Mohan, K., Srividya, A., Verma, A.K., 2010. ANP-based software
reliability prediction using PoCs and subsequent employment of orthogonal
defect classification measurements for risk mitigation during prototype
studies. International Journal of Systems Assurance Engineering and
Management 1 (1), 11–16.
Mann, H.B., Whitney, D.R., 1947. On a test of whether one of two random
variables is stochastically larger than the other. Annals of Mathematical
Statistics 18 (1), 50–60.
Marshakova, I.V., 1981. Citation networks in information science. Scientometrics
31 (1), 13–16.
McCaffery, F., Burton, J., Richardson, I., 2010. Risk management capability
model for the development of medical device software. Software Quality
Journal 18 (1), 81–107.
Please cite this article as: Neves, S.M., et al., Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated
Technology-Based Firms, International Journal of Project Management (2013), http://dx.doi.org/10.1016/j.ijproman.2013.02.007
View publication stats
MSF—Microsoft, 2002. Microsoft Solutions Framework: MSF Risk Management
Discipline v. 1.1: Microsoft. Available in: http://www.microsoft.com/msf
(Accessed: 18 set. 2009).
Murphy, A., Ledwith, A., 2007. Project management tools and techniques in
high-technology SMEs. Management Research News 30 (2), 153–166.
Na, K.-S., Simpson, J.T., LI, X., Singh, T., Kim, K.-Y., 2007. Software
development risk and project performance measurement: evidence in Korea.
Journal of Systems and Software 80 (4), 596–605.
Nakatsu, R.T., Iacovou, C.L., 2009. A comparative study of important risk
factors involved in offshore and domestic outsourcing of software
development projects: a two-panel Delphi study. Information Management
46 (1), 57–68.
Neef, D., 2005. Managing corporate risk through better knowledge management.
The Learning Organization 12 (2), 112–124.
Nonaka, I., Takeuchi, H., 1995. The Knowledge-creating Company: How
Japanese Companies Create the Dynamics of Innovation. Oxford University
Press, New York.
Nunnally, J.C., Bernstein, I.H., 1994. Psychometric Theory. McG. Hill, New York.
Pemsel, S., Wiewiora, A., 2013. Project management office a knowledge broker
in project-based organisations. International Journal of Project Management
31 (1), 31–42.
Persson, J.S., Mathiassen, L., Boeg, J., Madsen, T.S., Steinson, F., 2009.
Managing risks in distributed software projects: an integrative framework.
IEEE Transactions on Engineering Management 56 (3), 508–532.
PMI—Project Management Institute, 2008. A Guide to the Project Management
Body of Knowledge (PMBOK® Guide).
Radas, S., Bozic, L., 2009. The antecedents of SME innovativeness in an
emerging transition economy. Technovation 29 (6–7), 438–450.
Rahman, R.A., 2011. Knowledge sharing practices: a case study at Malaysia's
healthcare research institutes. The International Information & Library
Review 43 (4), 207–214.
Rodriguez-Repiso, L., Setchi, R., Salmeron, J.L., 2007. Modelling IT projects
success: emerging methodologies reviewed. Technovation 27 (10), 582–594.
Ropponen, J., Lyytinen, K., 2000. Components of software development risk:
how to address them? A project manager survey. IEEE Transactions on
Software Engineering 26 (2), 98–112.
RUP—Rational Software Corporation, 2003. Rational unified process: best
practices for software development teams. Rational Software White Paper,
TP026B, Rev 11/01: IBM. Available in: bhttp://www.ibm.comN. Accessed:
12 set. 2009.
Saaty, T.L., 1990. Multicriteria Decision Making. The Analytic Hierarchy
Process: Planning, Priority Setting, Resource Allocation, 2nd ed. RWS
Publications, Pittsburgh.
Schmidt, R., Lyytinen, K., Keil, M., Cule, P., 2001. Identifying software project
risks: an international Delphi study. Journal of Management Information
Systems 17 (4), 5–36.
SEBRAE—Serviço brasileiro de apoio às micro e pequenas empresas, 2005.
Boletim Estatístico de Micro e Pequenas empresas. Brasília. Available in:
http://www.sebrae.com.br (Accessed: 13 fev. 2010).
SEI, Software Engineering Institute, 2006. CMMI® for Development. Staged
Representation, Version 1.2, Technical Report (06tr008).Software Engineering
Institute, Carnegie Mellon University, Pittsburgh, PA (Available in:
bhttp://www.sei.cmu.edu/reports/06tr008.pdfN. Accessed: 12 set. 2009).
SOFTEX—Associação para Promoção da Excelência do Software Brasileiro,
2006. MPS.BR – Melhoria de processo do software brasileiro, versão 1.1,
maio 2006: Softex. Available in: www.softex.br (Accessed: 19 set. 2009).
Wallace, L., Keil, M., Rai, A., 2004. Understanding software project risk: a
cluster analysis. Information Management 42 (1), 115–125.
White, D., Fortune, J., 2002. Current practice in project management—an
empirical study. International Journal of Project Management 20 (1), 1–11.
Yin, R.K., 2009. Case Study Research: Design and Methods, Fourth ed. Sage
Publications, Inc., Thousand Oaks, CA.