Search results

The purpose of this paper is to investigate the relative importance of project management (PM) competences across the different stages of a software project life cycle to identify competence development gaps and opportunities.

A deductive and quantitative approach was adopted to address the research questions with a web-based survey for data collection.

After reviewing the context of competences and PM competences, the importance of the PM competences overall and for specific stages in the project life cycle was analysed. The result highlights that functional and meta-competences are perceived to be the most important competence dimensions for software project practitioners.

This study makes three contributions. First, it consolidates PM competences into a set of 20 within four competence dimensions. Second, it prioritises these competences across the software project life cycle. Third, it identifies the significance of the inter-relationship between PM competences and project life cycle to reveal PM competence development gaps and opportunities.

The purpose of this paper is to present a life cycle phase of a software development project which is substantial for the success of the project. This paper visualizes the project start-up phase from suppliers’ perspective.

The method is a theory building from case studies. The data were collected from three software supplier firms by conducting process modeling separately in each firm.

The study resulted in a model of a supplier’s software project start-up which includes start-up practices and involved roles. The results indicate that project start-up is an integral and structured phase of project life cycle, which influences the execution of a software development project, especially from the supplier’s perspective in the project business context.

The study focuses on the start-up phase of software development projects delivered to external customers. Therefore, developed project start-up model is applicable as such in software supplier firms.

The project start-up model presented in this paper indicates that project start-up is a complex and multi-dimensional activity in a supplier firm. This study suggests that if the project start-up phase is clearly defined, planned and followed in a supplier firm, it reduces confusion and miscommunication among the people involved in the project and helps to achieve the business goals of a project.

This study emphasizes that it is necessary to make a distinction between the perspectives of the customer and the supplier when studying projects in the project business context. The findings contribute the new knowledge for managing outsourced software development projects.

Agile principles have been widely used in software development team practice since the creation of the Agile Manifesto. Studies have examined variables related to agile principles without systematically considering the relationships among key team, agile methodology, and process variables underlying the agile principles and how these variables jointly influence the achievement of software development agility. In this study, the authors tested a team/methodology–process–agility model that links team variables (team autonomy and team competence) and methodological variable (iterative development) to process variables (communication and collaborative decision-making), which are in turn linked to software development agility (ability to sense, respond and learn).

Survey data from one hundred and sixty software development professionals were analyzed using structural equation modeling methods.

The results support the team/methodology–process–agility model. Process variables (communication and collaborative decision-making) mediated the effects of team (autonomy and competence) and methodological (iterative development) variables on software development agility. In addition, team, methodology and process variables had different effects on the three dimensions of software development agility.

The results contribute to the literature on organizational IT management by establishing a team/methodology–process–agility model that can serve as a basis for developing a core theoretical foundation underlying agile principles and practices. The results also have practical implications for organizations in understanding and managing holistically the different roles that agile methodological, team and process factors play in achieving software development agility.

This study aims to identify the competencies of small- and medium-sized enterprises’ (SMEs) entrepreneurs in the software sector and the perceived level of attainment in each competency. It also examines whether these competencies and their levels affect business turnover and growth (in terms of business scale and duration).

To accomplish this purpose, the study took a quantitative approach, involving a survey of 33 SME entrepreneurs, which was then processed using statistical tests, including chi-square test, Kruskal–Wallis test and ordinal regression.

There were four findings of the study. Firstly, software SME entrepreneurs need 17 competencies, with high levels of soft competencies being required and average levels of technical competencies. Secondly, there are significant differences in perceived levels of customer service orientation (p = 0.089) depending on the scale of the business and in perceived levels of project management (p = 0.087) depending on the duration of the business. Thirdly, customer service orientation (p = 0.031) and project management (p = 0.01) both have a significant influence on business revenues. Fourthly, there were significant gaps in perceived levels of competency (p < 0.05) in achievement orientation, customer service orientation and project management.

There is existing research that conducts competency mappings at the managerial level in large-scale organizations; however, this sort of research in relation to SME entrepreneurs is still lacking. The present study seeks to fill this gap. It also maps integrated entrepreneurial competencies, including soft and technical competencies; a focus that is lacking in previous studies.

While the choices available for project management methodologies have increased significantly, questions remain on whether project managers fully consider their alternatives. When project categorization systems and criteria are not logically matched with project objectives, characteristics and environment, this may provide the key reason for why many software projects are reported to fail to deliver on time, budget or do not give value to the client. The purpose of this paper is to identify and categorize critical success factors (CSFs) and develop a contingency fit model contrasting perspectives of traditional plan-based and agile methodologies.

By systematically reviewing the previous literature, a total of 37 CSFs for software development projects are identified from 148 articles, and then categorized into three major CSFs: organizational, team and customer factors. A contingency fit model augments this by highlighting the necessity to match project characteristics and project management methodology to these CSFs.

Within the three major categories of CSFs, individual factors are ranked based on how frequently they have been cited in previous studies, overall as well as across the two main project management methodologies (traditional, agile). Differences in these rankings as well as mixed empirical support suggest that previous research may not have adequately theorized when particular CSFs will affect project success and lend support for the hypothesized contingency model between CSFs, project characteristics and project success criteria.

This research is conceptual and meta-analytic in its focus. A crucial task for future research should be to test the contingency fit model developed using empirical data. There is no broad consensus among researchers and practitioners in categorizing CSFs for software development projects. However, through an extensive search and analysis of the literature on CSFs for software development projects, the research provides greater clarity on the categories of CSFs and how their direct, indirect and moderated effects on project success can be modelled.

This study proposes a contingency fit model and contributes towards developing a theory for assessing the role of CSFs for project success. While future empirical testing of this conceptual model is essential, it provides an initial step for guiding quantitative data collection, specifies detailed empirical analysis for comparative studies, and is likely to improve clarity in debate. Since previous studies have not rigorously assessed the impact of fit between project characteristics, project environment and project management methodology on project success, additional empirically robust studies will help to clarify contradictory findings that have limited theory development for CSFs of software development projects to date.

Previous research for software development projects has frequently not fully incorporated contingency as moderation or contingency as fit (traditional vs agile). This research sets out to develop fully a contingency fit perspective on software development project success, through contrasting traditional plan-driven and agile methodologies. To do this, the paper systematically identifies and ranks 37 CSFs for software projects from 148 journal publications and holistically categorizes them as organizational, team, customer and project factors.

The purpose of this study is to apply the concept of organizational ambidexterity as a conceptual lens to increase the understanding of tensions between exploitation (continuity) and exploration (change) in Agile software development (ASD) project teams, and particularly the balancing (ambidextrous) strategies utilized.

A conceptual framework was constructed from interdisciplinary sources on ambidexterity. A literature review of publications on ambidexterity in ASD was then performed, and the results from the selected publications were classified according to an extension of the conceptual framework.

Contextual ambidexterity in ASD is affected by the four basic coherent concepts: time, task, team and transition. The study found that most ambidextrous factors and strategies were task and team-related. In addition, a mixture of hard (performance) strategies and soft (social) strategies is needed in order for people/teams to (be able to) become ambidextrous.

To provide a better understanding of ASD, it is important to identify a broader set of ambidextrous factors and strategies that can impact ASD project teams. The expanded conceptual framework can serve as a basis for future empirical research and provide insights to practitioners on how to strengthen ambidexterity in ASD projects.

The contribution is of great importance for ASD research and practice, as ASD methods are a popular method for managing projects within ASD and in other nonsoftware organizations. In addition, as more and more organizations struggle to deal with rapidly changing environments, interest in the phenomena of paradoxical tensions and the strategy (ambidexterity) to deal with these tensions increase.

The paper seeks to investigate whether project managers regard software development projects as design problems or production problems.

Project management literature was examined to determine what evidence there should be to indicate whether a software development project was regarded as a problem to be solved or a product to be produced. Data were then collected through structured interview of project managers currently engaged in managing software development projects. The data were analysed to determine how project managers regarded their projects and whether this matched a theoretical expectation.

The empirical data indicated that most project managers regard their projects as production problems, where it is assumed that the underlying problem is largely understood, the project encapsulated in a planned schedule of activities and there will be an emphasis on monitoring the project against the planned progress.

Owing to the small sample size of fewer than 30 project managers, external validity is weak. More research is needed to confirm these results over a larger sample and to probe more subtle orientation to production or design projects.

The research developed a simple test to indicate the degree of novelty of the application to be developed. The test indicates whether the application is novel and should be treated as a design problem, or well known and therefore should be treated as a production problem.

The paper draws attention to the need for project managers to evaluate the type of application to be developed and to adopt an appropriate project management approach. The paper also provides a simple test to achieve that objective.

The purpose of this paper is to propose an in-depth analysis of online communities of practice that support the innovative development of web applications. The analysis is aimed at understanding the preeminent characteristics of communities of practice that can favour the process of innovation (conceptualisation and realization of a web application) and if these characteristics differ in the diverse phases of a software development project (requirement specification, design, implementation and verification).

The authors adopted a multiple case study research design, selected 29 communities of practice related to the development of web applications and classified them recognizing the different practices that refer to the different phases of the innovation process of web-applications software development. Finally, the authors focussed on seven communities comparing five important dimensions for each one.

The results of the empirical analysis show that the best practices are different, considering the different phases of the project, and that these practices can be strategies directed at members to attract them and also, strategies directed at the community to permit collaboration.

The paper proposes an important and new insight into the management of virtual communities of practice (VCoP). The authors supposed that the ways to manage a VCoP could depend on project phases. In particular, the management practices of community should differ according to the different project phases, i.e. requirements specification, design, implementation and verification of the software. Literature in this sense presented only research focussed on the different effects of virtualness on teams depending on the length of team duration and on communication efforts.

Scrum, an agile software development method, has gained major interest among software development organizations. The scrum master should be well equipped with specific leadership traits and exhibit leadership behavior to effectively manage his/her team. However, in a distributed team, which is spread across geographies, having scrum master to lead the project team at each location is not viable. Therefore, every member in the team is expected to have the capability to become one. This paper aims to explore the leadership mechanisms desired for effective functioning of distributed self-organized scrum team members, leading to project success and overall customer satisfaction.

A qualitative research methodology with an open-ended questionnaire is followed by semi-structured in-depth interviews. The unit of analysis is a scrum master.

The qualitative findings unearth the kind of leadership mechanisms required for scrum masters and the team members in a self-organizing scrum team, leading to their project success and customer satisfaction. It includes a set of leadership approaches and behaviors explicitly related to the role of scrum masters. Both inductive and deductive approaches are used to develop a leadership framework applicable for distributed self-organized scrum teams.

The proposed framework can be empirically tested with a large number of teams and more software organizations.

Organizations can use these identified specific leadership approaches and behaviors as parameters for identifying and selecting the potential scrum masters. They can be further trained on them to be an effective scrum master.

There is scant literature on the leadership mechanisms necessary for distributed scrum teams and their impact on project performance. This paper addresses this gap.