Risk management in software projects through Knowledge Management techniques: Cases in Brazilian Incubated Technology-Based Firms

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

b

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 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: [email protected] (S.M. Neves), [email protected] (C.E.S. da Silva), [email protected] (V.A.P. Salomon), [email protected] (A.F. da Silva), [email protected] (B.E.P. Sotomonte).

Despite the improvements already achieved, many software 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

0263-7863/$36.00 © 2013 Elsevier Ltd. APM and IPMA. All rights reserved. http://dx.doi.org/10.1016/j.ijproman.2013.02.007 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 managing risk in projects is knowledge. Such statements provide a useful link between risk management and knowledge management. Thus, it is intended to answer the following research question: How Knowledge Management techniques contribute to risk management in software development projects? Based on the research question, this article aims at analyzing the integration of Knowledge Management techniques to the activity of Risk Management in software development projects of micro and small Brazilian Incubated Technology-Based Firms (ITBF). It has as specific aims: (1) To analyze the main risk factors in software development projects of ITBF; and (2) To assess the techniques of Knowledge Management (KM) as used by the ITBF in the management of the risk factors of software development projects. Justifications for research development make reference to the following statements:

Fig. 1 shows a diagnosis result performed by Product Development Center of Technology-Based Incubator of Itajubá (INCIT) in eight ITBF software projects in 2008 and 2009. The results showed that the projects major part is carried out without the use of a formal methodology, this one being the main activity expected by the managers for the processes improvement (100%). Other expected activities were the lessons learned structure (75%) and the projects risks analysis (63%), both of them as a way to avoid working again and keeping up knowledge. • Most importantly, the academic contribution: Gaps in literature regarding theoretical and practical research on risk management (Bannerman, 2008), related to project management applied to small firms (Murphy and Ledwith, 2007; White and Fortune, 2002); and Knowledge Management in the context of Risk Management approaches (as can be seen in Section 2.2).

• Relevance of the theme: After performing a review of risks in the software development process, Bannerman (2008) concluded that there is a need for better Risk Management, both in research and in practice. According to Wallace et al. (2004), “Unfortunately, despite these recommendations, there are relatively few tools available to help project managers to identify and categorize risk factors in order to develop effective strategies.” • Relevance of the objects of study: The objects of study are 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 survival; not necessarily meaning that the technology must be new or innovative. For Radas and Bozic (2009), small and medium-sized firms are considered the engines of economic growth, as well as job creation; and because of this importance, developed and developing countries are interested in learning ways these firms carry out innovations. The Serviço Brasileiro de Apoio às Micros e Pequenas Empresas—SEBRAE (2010) reports the, micro and small firms responded, in 2010, by 99% of the total formal firms number, by 51.6% of private no-agricultural formal employments and for almost 40% of the salary mass. According to the similar survey, carried on in 2005, 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% after three years and 59.9% after four years. Opposed to this aspect, the 2006 Panorama report by Associação Nacional de Entidades promotoras de Empreendimentos de Tecnologias Avançadas - ANPROTEC (2006a, 2006b) showed a closing rate of incubated firms of 20%. In five years, the movement of the incubators grew by over 300%, being 70% of the generated business by technological-based firms. This information underlines the importance of incubators related to the survival rate of micro and small firms, the importance of ITBF for the economical growth and the development of surveys in this area.

The paper is structured as follows. Section 1 presents the research, its objectives and contributions; Section 2 states the theoretical foundation of Risk Management applied to software development projects, approaches that address the theme of Risk Management in software development, knowledge sharing and transference and Knowledge Management techniques; Section 3 defines the classification of the research and the planning of the case study; Section 4 presents the form of data collection; Section 5 analyzes the result; and finally, Section 6 presents discussion, conclusion and direction for future research.

2. Literature review 2.1. Risk Management in software development projects For Wallace et al. (2004), risks in software projects consists of a number of factors or conditions that may represent a serious threat to the successful completion of the project. They imply quantifying the importance of such risks, assessing their frequency and their potential impact on project performance; as well as in the development of strategies of control (Huang and Han, 2008). There are important studies relating to the various risks of software development projects, and the foci of some of this research are: • Mitigation of risks in software projects using methods of decision aid as the Analytic Network Process—ANP (Krishna Mohan et al., 2010). • Identification of risk factors (Bannerman, 2008; Costa et al., 2007; Han and Huang, 2007; Nakatsu and Iacovou, 2009). • Structuring the framework for risk management (Dey et al., 2007) and how specific conditions impact risk perception and the decision to continue the projects (Du et al., 2007). • Use of a risk checklist (Keil et al., 2008), a record of software projects that were canceled, and the delivery results of those that have not been canceled (Emam and Koru, 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 Plan the management Identify Prepare qualitative analysis Prepare quantitative analysis Plan responses Solve Monitor and control Report Learn

Boehm (1988)

ISO/IEC 15.504 (1999)

X X X X X X

X X X X X X X

MSF (2002) X X X X X X Implicit X

RUP (2003) X X X X X X X

ISO 10006 (2003)

AS/NZS 4360 (2004)

CMMI (SEI, 2006)

MPS.BR (SOFTEX, 2006)

PMBoK (PMI, 2008)

X X X X X X Implicit Implicit

X X X X X X X X Implicit

X X X X X X Implicit Implicit Implicit

X X X X X X X

X X X X X X X 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 environment 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 responsibilities 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.

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 networks, 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 businesses 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:

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

• 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

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

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

Doctorate

Master's degree

Specialization

Complete higher degree

Incomplete higher degree

High school

–

1

1

7

6

–

Last completed course

Age (years) Up to 24

From 25 to 34

From 35 to 44

From 45 to 54

Over 55

7

8

–

–

–

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%)

–

–

Average duration of projects

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 et al. (2001) were used to assess the respondents on a scale of 1 to 5, the probability of risk occurring, and the impact of such risks should they occur. • In the second stage, for each risk factor proposed by Schmidt et al. (2001), KM techniques listed in Section 2.4 were introduced which allowed respondents to determine which KM techniques could best facilitate the analysis of the proposed risk factors; in addition to identifying those techniques associated with modes of knowledge conversion proposed by Nonaka and Takeuchi (1995) according to Appendix A. • The third stage referred to collecting general information about the firms and respondents. The pilot test was conducted in two of the Brazilian incubated firms from Technology-Based Incubator of Montes Claros Educational Foundation (INCET). The two firms stood out in their area of expertise due to activities related to software projects and because they presented different times of incubation. The pilot test resulted in proactive improvements in the research questionnaire and the inclusion of the failure to obtain financing and high taxes as two new risk factors.

The following sequence for data collection was used: securing approval from top management to conduct the research; informing the managers of the firms about the mutual benefits of the study, with specific reports having been sent to each company; convening meetings with managers and software developers; document analysis, consisting of portfolios of the company and its customers, including work procedures and knowledge repositories; implementing the search questionnaire; and conducting the interviews. During this phase the perceptions of the respondents and the researchers were recorded in order not

Table 3 Ranking of the major risk factors according to managers and developers. Question

Risk factors

Mean

13

Scope or goals are often unclear or misinterpreted (5.1) Change of scope/goals (5.2) Lack of an effective methodology for managing projects (4.3) Volatility of the personnel involved (11.2) Deadlines and execution times of tasks poorly estimated (8.1) Lack of cooperation from users (3.3) Inadequate management of change (4.1) Constant changes in the requirements (6.1) Failure to obtain user commitment by the project manager (2.3) Change in ownership of the product or the senior manager of the project (1.5)

6.70

14 10 26 20

4. Data collection

7 8 16 3

Data were collected during the months of December, 2009, and January, February and March of 2010, totaling fifteen respondents (nine managers and six software developers).

1

6.26 5.97 5.89 5.78 5.75 5.73 5.66 5.60 5.56

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. 5.1. Analysis of the major risk factor Table 3 lists the top ten risks factors, according to their average probability of occurrence and impact for managers and developers. The reliability of the questionnaire was calculated after considering the degree of homogeneity of the set of responses by Cronbach's alpha, which provides internal consistency values. Although there is no absolute standard, Cronbach's alpha values equal to or greater than 0.70 reflect an acceptable reliability (Hair et al., 1998; Nunnally and Bernstein, 1994). For this analysis we obtained a Cronbach's alpha of 0.933, indicating high consistency. The geometric mean was used to rank the data. The main risk factor for managers and developers (scope or goals are often unclear or misinterpreted) has been assessed through research protocol, also being checked through an interview. Managers, as well as developers, considered the fact 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” is present as a consequence of the first one and reaffirms its importance. It also matches with Emam and Koru (2008) researches, according to them scope and requirements are the main reasons for the project cancelation. It was noticed that the third risk factor (lack of an effective methodology for managing projects) was one of the most issues commented by the developers, who fell much more comfortable when they follow

an established pattern, a fact proven though the development procedure analysis. This risk factor boosts the surveys conducted at ITBF (Fig. 1), where 100% of the evaluated firms considered as an opportunity of a systematic improvement and implementation for project management and 63% of a risk analysis system. The technique of cluster analysis was used to evaluate the data generated by Table 3. For Everitt (1993) groups formed in this analysis are similar to each other internally because the variance within the cluster is minimal; and they have differences related to other groups because the variance between is maximal. A similarity level of 34% was obtained as a result the dendogram presented in Fig. 4. The group formed proved to be relatively homogeneous, which allowed for a classification into three categories: high risk, moderate risk and low risk (Table 4), a description of the issues can be seen in Appendix A. Further analysis of the data obtained in the survey is presented: • Regarding the level of awareness of those interviewed for Risk Management, the majority was high (47%). However, 87% of respondents reported not having formal training in the necessary methodology. • With respect to which approach to Risk Management would be implemented at the company, most of them still prefer methods as a matrix of risks and approaches as proposed by PMBOK.

Table 4 Result of cluster analysis for risks factors. Cluster

Groups formed

1

High risks

2 3

Moderate risks Low risks

Questions

Q01, Q05, Q20, Q03, Q26, Q08, Q06, Q07, Q17, Q10, Q16, Q13, Q14, Q12, Q21, Q28, Q23, Q24 Q02, Q27, Q09, Q22, Q18, Q11, Q29, Q25, Q19, Q15 Q04, Q30, Q31

Mean

General

Probability

Impact

1.929

3.585

5.514

1.730 1.580

2.986 1.769

4.716 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 Poorly estimated costs Staff involved insufficiently/inadequately

7.000 7.000 6.000

4.500 2.000 2.000

0.0471 0.0054 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 comfortable 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 Badly estimated task execution deadlines Scope or goals are often unclear or misinterpreted Change of scope/goals Poorly estimated costs Requirements misinterpreted and/or poorly defined in the early development Lack of knowledge/skills of the project team Change in ownership of the product or the senior project manager No planning or inadequate planning Constant changes in requirements Staff involved insufficiently/inadequately Lack of skills for project management

Ranking of the research (2010)

Schmidt–HKG, USA e FIN (2001)

Schmidt–HKG (2001)

Schmidt–USA (2001)

Schmidt–FIN (2001)

1 2 3 4 5

– – 7 – 2

– – 5 – 7

– 9 10 – 2

7 – 19 18 6

6 7

5 –

13 5

11 –

3 –

8 9 10 11

– 6 10 –

– 8 15 –

– 14 13 5

5 9 15 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 Learn by doing 13 Training at work 11 Brainstorming 10 Customer interactions 9 Knowledge repositories 8 Formal education 8 Observation, imitation and practice 7 Scenarios, simulation and prototyping 7 Telephone conversations and 6 computer network Database skills 6 Multidisciplinary teams 5 Communities of practice 4 Narratives and oral stories 3 Metaphors, analogies, concepts, 3 hypotheses Total 113

12% 12% 10% 9% 8% 7% 7% 6% 6% 5%

Combination Internalization Socialization Socialization Socialization Externalization Combination Socialization Combination Combination

5% 4% 4% 3% 3%

Socialization Socialization Socialization Externalization Externalization

Fig. 5. Percentual of KM techniques currently used for risk management.

100%

(HKG—eleven respondents), Finland (FIN—thirteen respondents) 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 Meetings (face-to-face) Training at work Customer interactions Telephone conversations and computer network Brainstorming Formal education Multidisciplinary teams Communities of practice Knowledge repositories Scenarios, simulation and prototyping Database skills Learn by doing Observation, imitation and practice Metaphors, analogies, concepts, hypotheses Narratives and oral stories Total

Number of citations

Percentage

Conversion mode

264 146 133 116

18% 10% 9% 8%

Combination Socialization Socialization Combination

109 94 93 83 79 72

7% 6% 6% 6% 5% 5%

Socialization Combination Socialization Socialization Externalization Combination

69 69 50

5% 5% 3%

Socialization Internalization Socialization

46

3%

Externalization

35 1458

2% 100%

Externalization 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 Result of the Mann–Whitney test for the perception of KM techniques. KM techniques

Median Managers Developers P-Value

Training at work 9.00 Communities of practice 4.00 Multidisciplinary teams 4.00 Brainstorming 3.00 Customer interactions 7.00 Observation, imitation and practice 1.00 Narratives and oral stories 1.00 Metaphors, analogies, concepts, hypotheses 1.00 Knowledge repositories 3.00 Meetings (face-to-face) 20.00 Telephone conversations and computer 7.00 network Scenarios, simulation and prototyping 3.00 Formal education 7.00 Database skills 4.00 Learn by doing 2.00

11.50 5.50 4.50 6.5 11.00 2.50 2.00 2.50 4.00 11.00 4.00

0.5169 0.3768 0.8597 0.5557 0.6374 0.1753 0.4795 0.5169 0.4437 0.0392 0.3768

5.00 4.5 3.00 5.00

0.5169 0.4094 0.7237 0.0990

completed the first specific objective, which was to analyze the main risk factors in ITBF software development projects. 5.2. KM techniques used in the analysis of risk factors Table 7 presents the main KM techniques used by the evaluated firms considering the conversion of knowledge method proposed by Nonaka and Takeuchi (1995) according to Section 2.4. Table 8 contains a list of the primary KM techniques used by the surveyed firms that should be employed for the management of risk factors identified in software development projects. The Cronbach's alpha for this analysis was 0.956, indicating high internal consistency. As for KM, 67% of respondents conceded that they did not have formal training in the methodology for conducting activities in this area; nevertheless, they use the same techniques. Fig. 5 shows the percentage of KM techniques currently used by firms rated according to the SECI model proposed by Nonaka and Takeuchi (1995) as presented in Table 7. Fig. 6 shows the percentage of KM techniques that respondents consider to

be most suitable for management of risk factors, according to Table 8. The percentages were calculated using the weighted average, since some modes of conversion have a higher number, e.g. socialization. The main findings for this analysis are presented in the following sequence: • It can be seen in Fig. 5 that the conversion mode in use today by firms to analyze their risks is internalization (39%) using KM techniques and “learning by doing” (Table 7). • However, according to Fig. 6, the respondents clearly considered the most applicable conversion mode for the management of risk factors would, for the most part, be the combination mode (38%); specifically, KM techniques such as meetings and the use of computerized networks (Table 8). The technique of “meetings—face-to-face” is still the most commonly cited, though the technique of “training at work” 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 applicable to each risk factor identified. Mann–Whitney was used to test Proposition 2 that the managers and developers of the ITBF evaluated are in congruence regarding KM techniques most applicable to the management of the risk factors in software development projects (Table 9). It is notable that the only KM technique with a significant difference (b 0.05) was “meetings—face-to-face” (P-value 0.0392), having been cited more by managers than by developers. The perceptions for the remaining questions were equivalent; therefore, considering a total of 15 questions and a significance level of 5%, Proposition 2 is therefore accepted. The “work training” technique was the most cited by the developers than by the managers, which can indicate the need for improvements related to this practice. Completing this step met the second specific aim, which was to evaluate KM techniques used by the ITBF in the management of risk factors for software development projects. After presenting discussions and conclusions concerning the development of this work, this paper will close with a list of the techniques cited by respondents as the most suitable for 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) Meetings (13), customer interactions (8), brainstorming (5) Training at work (9), formal education (7), knowledge repositories (5) Training at work (6), phone conversations and computer networking (6), database skills (5), meetings (5), and knowledge repositories (5) Meetings (11), training at work (5), multidisciplinary teams (5), knowledge repositories (5)

Change of scope/objectives Lack of an effective methodology for managing projects Volatility of the personnel involved Deadlines and execution times of tasks poorly estimated

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 developers, 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.

11

In response to the research question, it was found that the contribution of KM techniques for the activity of risk management 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 identification 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 implementation 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.

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

12

S.M. Neves et al. / International Journal of Project Management xx (2013) xxx–xxx

Appendix A Table A1 Questionnaire used in the survey.

Q01

15-Learn by doing

16. Not applicable

14-Formal education

12-Documents, telephone conversations and computer network 13-Scenarios, simulation and prototyping

11-Meetings

10-knowledge repositories

9-Metaphors, analogies, concepts, hypotheses

8-Narratives and oral stories

7-Database skills

6-Observation, imitation and practice

5-Customer interactions

4-Brainstorming

3-Multidisciplinary teams

1-Training at work

Risk Factors

2-Communities of practice

Techniques

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

Q05

Failure to manage expectations

departments (2.4) 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

Q11

Improper definition of roles

Q12

Inadequate or

Q13

Scope or goals are often

Q14

Change of scope / goals (5.2)

Q15

Number of

project management (4.3) and responsibilities (4.4) nonexistent control (4.5) unclear or misinterpreted (5.1)

client's organizational units involved (5.5) Q16

Constant changes in the

Q17

Requirements misinterpreted

requirements (6.1) 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)

Q21

Lack of effective methodology

Q22

Attempt to

16. Not applicable

15-Learn by doing

14-Formal education

12-Documents, telephone conversations and computer network 13-Scenarios, simulation and prototyping

11-Meetings

10-knowledgerepositories

9-Metaphors, analogies,

concepts, hypotheses

8-Narratives and oral stories

7-Database skills

6-Observation, imitation and practice

4-Brain storming

5-Customer interactions

3-Multi disciplinary teams

2-Communities of practice

Risk Factors

1-Training at work

Techniques

or process development (9.1) adopt new development method/ technology during the project (9.2) Q23

Lack of knowledge /skills of

Q24

Lack of interpersonal skills of

the project team (10.1) managers in leading the project team (10.2) Q25

Staff involved insufficiently/

Q26

V olatility of the staff involved

Q27

Introduction of

Q28

Complicated dependencies on

inadequately (11.1) (11.2) new technologies (12.1) projects from multiple vendors, integration of technologies from various sources (13.2) Q29

No planning or inadequate

Q30

Failure to

Q31

High taxes (15.2)

planning (14.1) obtain financing (15.1)

Mark with an X the techniques of knowledge management that are used in your company aiming the risk management in projects.

References Aerts, K., Matthyssens, P., Vandendempt, K., 2007. Critical role and screening practices of European business incubators. Technovation 27 (5), 254–267. Anantatmula, V.S., Kanungo, S., 2010. Modeling enablers for successful KM implementation. Journal of Knowledge Management 14 (1), 100–113. ANPROTEC—Associação Nacional de Entidades Promotoras de Empreendimentos de Tecnologias Avançadas, 2006a. Número de incubadoras em operação no Brasil. Available in: http://www.anprotec.org.br (Accessed 27 mai. 2009). ANPROTEC—Associação Nacional de Entidades Promotoras de Empreendimentos de Tecnologias Avançadas, 2006b. Estudo, análise e proposições sobre as incubadoras de empresas no Brasil – Relatório Técnico. Available in: http://www.anprotec.org.br (Accessed 27 dez. 2012). AS/NZS 4360, 2004. Standards Australia and standards New Zealand. Risk Management. Sydney, NSW.0 7337 5904 1.

Baccarini, D., Salm, G., Love, P.E.D., 2004. Management of risks in information technology projects. Industrial Management and Data System 104 (4), 286–295. Bannerman, P.L., 2008. Risk and risk management in software projects: a reassessment. Journal of Systems and Software 81 (12), 2118–2133 . Barros, M.O., Werner, C.M.L., Travassos, G.H., 2004. Supporting risks in software project management. Journal of Systems and Software 70 (1–2), 21–35. Boehm, B.W., 1988. A spiral model of software development and enhancement. IEEE Computer 21 (5), 61–72. Boehm, B.W., 1991. Software risk management: principles and practices. IEEE Software 8 (1), 32–41. Bryman, A., Bell, E., 2007. Business Research Methods, 2nd ed. Oxford University Press, New York. 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 development: 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 Assessment—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.

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.

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