‘Requirements-Uncertainty’: Is it best formulated as a latent,aggregate or profile construct?

This paper identifies the strategies that experienced information systems (IS) project managers say they use to cope with requirements-uncertainty (RU) when managing development projects for external clients. It is shown that project managers (PMs) claim to use different strategies for coping with the different dimensions of requirements-uncertainty, as this notion has been formulated in IS literature. Based on this finding, it is proposed that perhaps requirements-uncertainty should be formulated as a profile construct, and not as a latent or aggregate construct, if it is to have pragmatic validity as a guide to action for project managers.     

A comparison of software project overruns - flexible versus sequential development models

Flexible software development models, e.g., evolutionary and incremental models, have become increasingly popular. Advocates claim that among the benefits of using these models is reduced overruns, which is one of the main challenges of software project management. This paper describes an in-depth survey of software development projects. The results support the claim that projects which employ a flexible development model experience less effort overruns than do those which employ a sequential model. The reason for the difference is not obvious. We found, for example, no variation in project size, estimation process, or delivered proportion of planned functionality between projects applying different types of development model. When the managers were asked to provide reasons for software overruns and/or estimation accuracy, the largest difference was that more of flexible projects than sequential projects cited good requirement specifications-and good collaboration/communication with clients as contributing to accurate estimates.     

Can software risk management improve system development: an exploratory study

Software risk management can be defined as an attempt to formalise risk oriented correlates of development success into a readily applicable set of principles and practices. Earlier research suggests that it can reduce the likelihood of a system failure. Using a survey instrument we investigate this claim further. The investigation addresses the following questions: (1) which characteristics of risk management practices; and (2) which other environmental and process factors (such as development methods, manager's experience) relate to improved performance in managing software risks? Our findings support in general the claim that the use of risk management methods improves system development performance. Yet, little support was found for the claim that specific risk management methods are instrumental in attacking specific software risks. Overall, risks are better managed with combined measures of having experienced project managers, selecting a correct project size, and investing in and obtaining experience in risk management deliberations.     

Components of software development risk: how to address them? Aproject manager survey

Software risk management can be defined as an attempt to formalize risk oriented correlates of development success into a readily applicable set of principles and practices. By using a survey instrument we investigate this claim further. The investigation addresses the following questions: 1) What are the components of software development risk? 2) how does risk management mitigate risk components, and 3) what environmental factors if any influence them? Using principal component analysis we identify six software risk components: 1) scheduling and timing risks, 2) functionality risks, 3) subcontracting risks, 4) requirements management, 5) resource usage and performance risks, and 6) personnel management risks. By using one-way ANOVA with multiple comparisons we examine how risk management (or the lack of it) and environmental factors (such as development methods, manager's experience) influence each risk component. The analysis shows that awareness of the importance of risk management and systematic practices to manage risks have an effect on scheduling risks, requirements management risks, and personnel management risks. Environmental contingencies were observed to affect all risk components. This suggests that software risks can be best managed by combining specific risk management considerations with a detailed understanding of the environmental context and with sound managerial practices, such as relying on experienced and well-educated project managers and launching correctly sized projects     

In-house software development: what project management practices lead to success?

Project management is an important part of software development, both for organizations that rely on third-party software development and for those whose software is developed primarily in-house. Moreover, quantitative survey-based research regarding software development's early, nontechnical aspects is lacking. To help provide a project management perspective for managers responsible for in-house software development, we conducted a survey in an attempt to determine the factors that lead to successful projects. We chose a survey because of its simplicity and because we hoped to find relationships among variables. Also, a survey let us cover more projects at a lower cost than would an equivalent number of interviews or a series of case studies. Our results provide general guidance for business and project managers to help ensure that their projects succeed.     

Managing uncertainty in software projects

Although it is impossible to predict problems that will occur in software projects, project managers can employ strategies that imbue their projects with greater resilience. Throughout a software project, a series of practices can be established to manage uncertainties. This paper proposes an approach to managing uncertainty in software projects. The approach seems to improve project performance and success. This work is based on the principles of evidence-based software engineering. We conduct an exploratory literature search and a systematic literature review. In addition, we carry out action research in a software development project. Semi-structured interviews were conducted to evaluate and improve this approach. Finally, we held a focus group to evaluate the final proposed approach. The exploratory review helped to characterise the difference between risk and uncertainty. The systematic literature review revealed five methods and 18 practices for reducing uncertainties. The action research applied some of these techniques and investigated whether they contributed to a better uncertainty management. In the semi-structured interviews, practical points of view were added to the approach. This work defines an approach to uncertainty management and describes strategies that allow team members to explicitly formalise and manage uncertainty in software projects.     

Undersizing software systems: third versus fourth generation software development

A critical component of information systems (IS) project management is completing projects on time; however, most software development efforts have completion time overruns. This study examines the prior research in IS project management for assessing the completion time for new software development projects and discusses a project management phenomenon where the expected time for project completion is undersized. At one firm two groups of software development projects are examined: (1) Cobol projects (third generation) and (2) Natural (fourth generation). It was found that both the Cobol and Natural projects experienced similar overruns. Undersizing is posited as the explanation.     

Rule Breaking in New Product Development – Crime or Necessity?

The purpose of this study is to investigate the effect of applying general rules in organizations to govern multiple new product development projects. Data were collected in structured interviews with project managers and project members from seven successful projects within Swedish companies. Results show that projects either broke rules or that organizations had developed strategies to cope with the risk of rules preventing the progress of the projects. The project managers of the rule following projects reported lack of rule breaking to be the result of the rule design at each company, intending to minimize the risk of rules preventing the progress of projects. With the exception of the manager of the rule changing/removing project, project managers show a relaxed attitude to breaking general rules that hinder project progress. The study indicates that frameworks of common project management rules increase the risk of delay in new product development projects, unless strategies of rule breaking or dynamic rule modification are applied. Applications of emergent standard management philosophies and practices to innovation are discussed.     

关于项目管理的几点体会

随着各行各业IT建设的不断发展,越来越多项目的投入建设和使用,然而,其中失败的例子也并不少见,因此,项目管理也日益受到各方的重视,究竟项目管理的问题何在,文章结合笔者多年从事IT项目的实践、经验和思考,对项目管理进行了初步的探讨和阐述,供各位同行参考。     

Project managers in global software development teams: a study of the effects on productivity and performance

Globalization is having a deep impact on today’s world economy. One of the most affected industries is the software industry. Recently, global software development (GSD) has gained a lot of attention. This new trend of producing software is influencing all software processes, including human resource management. The aim of this study is to provide an overview of the implications of GSD for software project managers by analyzing project performance from different perspectives such as the 360-degree feedback evaluation. Results show that performance of GSD projects is lower than in-house projects, but apart from that, this study reveals that there are also negative consequences for software project managers, which need to be taken into account. For instance, the experiment revealed a lack of attention to tasks by software project managers and, as a consequence of this, performance losses. The main conclusions of this research may be valuable for software development organizations.     

A statistical analysis of the effects of Scrum and Kanban on software development projects

Traditionally, software development processes have relied on the use of the “Waterfall” and “Vee” models. Later, Agile methodologies were used to handle the challenges of managing complex projects during the development phase. Agile methodologies are a group of incremental and iterative methods that are more effective, and have been used in project management. Kanban and Scrum are two powerful Agile project management approaches in software development. The objective of Scrum and Kanban is achieved by optimizing the development process by identifying the tasks, managing time more effectively, and setting-up teams. A review of the literature reveals that there is a lack of statistical evidence to conclude which methodology is more effective in dealing with the traditional project management factors of budget handling, risk control, quality of the project, available resources, having clear project scope, and schedule handling. This research statistically compares the effectiveness of the Scrum and Kanban methods in terms of their effects on the project management factors for software development projects. Numerical analysis is performed based on survey responses from those with experience in the Scrum and Kanban methods. Results suggest that both Scrum and Kanban lead to the development of successful projects, and that the Kanban method can be better than the Scrum method in terms of managing project schedule.     

Fear of trying: the plight of rookie project managers

Most software engineers do not want the hassle of project management. Poor project management is the number one cause of software project failure. How do we grow good project managers? What do we teach the rookies who have just been appointed to lead their first software project? Regardless of the training or mentoring approach you use, I suggest focusing on four major attributes, which I describe in their order of importance: communication, negotiation, organization and facilitation     

Does risk matter? Disengagement from risk management practices in information systems projects

Risk management and ‘routine-based reliability’ is considered fundamental to project performance. Existing theories of project risk management do not fully explain why project managers stop practicing risk management information systems (IS); however, constructs drawn from organisation theory offer insights into how and why such disengagement occurs. The study examines risk management practices in 21 IS projects within 10 organisations. By focusing on risks that resulted in significant events and mapping backwards over time the practices associated with those risks, we identify that in all but five projects the manager had disengaged from prescribed risk management before executing risk responses. In most projects, the majority of formally identified and assessed risks remained unallocated and untreated. A laddering technique was used to help explain why this transpired. We found five key underlying beliefs that governed project managers’ risk management attitudes and actions.     

Blending bureaucratic and collaborative management styles to achieve control ambidexterity in IS projects

Managing information systems (IS) projects requires what we refer to as ‘control ambidexterity’, which is the use of different types of control to meet conflicting demands. This leads to the use of contrasting styles of IS project management and creates tensions in managerial practice, neither of which are well understood. We address this theoretical gap in our understanding based on an exploratory case study of an IS implementation project in the financial services industry. Adopting the lens of management styles as a meta-theoretical perspective, we sought to address two research questions: (1) Which management style(s) do IS project managers draw upon in practice and why? (2) What kinds of tensions result for IS project managers and team members from drawing upon contrasting management styles in combination – and how do IS project managers and team members deal with these tensions? Two contrasting styles of management emerged from our data – bureaucratic and collaborative – that are drawn upon by IS project managers to achieve control ambidexterity. Furthermore, drawing upon these two different styles in combination within the confines of a single project creates tensions. We explore these tensions and present an illustrative example of how IS project managers can deal with these tensions successfully in practice. Specifically, we find that they can be dealt with effectively by a tandem of two project managers who share responsibility for managing the IS project. The findings of this study have important implications for our understanding of control ambidexterity in IS projects.     

Project termination doesn't equal project failure

One of the most frequently cited software project statistics comes from the Standish Group's 1995 Chaos report (http://www.standishgroup.com/visitor/ chaos.htm): “A staggering 31.1 percent of [software] projects will be canceled before they ever get completed.” The Chaos report, and numerous documents citing it, label these canceled projects as “failed” and imply that all 31.1 percent of them were canceled because of poor software management. This implication is both false and hazardous. It is false because, particularly in an era of rapid change, a lot of software projects are properly started, well managed, and properly terminated before completion because their original assumptions have changed. It is hazardous because it often leaves software managers with the following temptation: “It's becoming clear that continuing this project will waste company resources. I should probably have the project canceled now, but that would make me the manager of a failed project and wreck my career. I'll be better off if I say nothing, keep the project going, and look for a new project to transfer to.” To counter this train of thought, the author reviews the main sources of project termination determined in the Chaos report, and estimates how likely each termination source applies to a well- or poorly managed project     

A survey study of critical success factors in agile software projects

While software is so important for all facets of the modern world, software development itself is not a perfect process. Agile software engineering methods have recently emerged as a new and different way of developing software as compared to the traditional methodologies. However, their success has mostly been anecdotal, and research in this subject is still scant in the academic circles. This research study was a survey study on the critical success factors of Agile software development projects using quantitative approach.

Based on existing literature, a preliminary list of potential critical success factors of Agile projects were identified and compiled. Subsequently, reliability analysis and factor analysis were conducted to consolidate this preliminary list into a final set of 12 possible critical success factors for each of the four project success categories – Quality, Scope, Time, and Cost.

A survey was conducted among Agile professionals, gathering survey data from 109 Agile projects from 25 countries across the world. Multiple regression techniques were used, both at the full regression model and at the optimized regression model via the stepwise screening procedure. The results revealed that only 10 out of 48 hypotheses were supported, identifying three critical success factors for Agile software development projects: (a) Delivery Strategy, (b) Agile Software Engineering Techniques, and (c) Team Capability.

Limitations of the study are discussed together with interpretations for practitioners. To ensure success of their projects, managers are urged to focus on choosing a high-caliber team, practicing Agile engineering techniques and following Agile-style delivery strategy.     

IssuePlayer: An extensible framework for visual assessment of issue management in software development projects

This article presents a software visualization framework which can help project managers and team leaders in overseeing issues and their management in software development. To automate the framework, a dashboard tool called IssuePlayer is developed. The tool is used to study the trends in which different types of issues (e.g., bugs, support requests) are submitted, handled and piled up in software projects and use that information to identify process symptoms, e.g., the times when the code maintenance team is not responsive enough. The interactive nature of the tool enables identification of the team members who have not been as active as they were expected to be in such cases. The user can play, pause, rewind and forward the issue management histories using the tool. The tool is empirically evaluated by two industrial partners in North America and Europe. The survey and qualitative feedback support the usefulness and effectiveness of the tool in assessing the issue management processes and the performance of team members. The tool can be used complementarily in parallel with textual information provided by issue management tools (e.g., BugZilla) to enable team leaders to conduct effective and successful monitoring of issue management in software development projects.     

The role of object-oriented metrics

Perhaps the most common concern of project managers who use or who are about to use object technology is for more measurement tools. There is, in fact, an extensive literature on software metrics, including much that pertains to object-oriented development, but surprisingly little of it is of direct use to actual projects. The author presents a classification of software metrics and five basic rules for their application     

The optimization of success probability for software projects using genetic algorithms

The software development process is usually affected by many risk factors that may cause the loss of control and failure, thus which need to be identified and mitigated by project managers. Software development companies are currently improving their process by adopting internationally accepted practices, with the aim of avoiding risks and demonstrating the quality of their work.This paper aims to develop a method to identify which risk factors are more influential in determining project outcome. This method must also propose a cost effective investment of project resources to improve the probability of project success.To achieve these aims, we use the probability of success relative to cost to calculate the efficiency of the probable project outcome. The definition of efficiency used in this paper was proposed by researchers in the field of education. We then use this efficiency as the fitness function in an optimization technique based on genetic algorithms. This method maximizes the success probability output of a prediction model relative to cost.The optimization method was tested with several software risk prediction models that have been developed based on the literature and using data from a survey which collected information from in-house and outsourced software development projects in the Chilean software industry. These models predict the probability of success of a project based on the activities undertaken by the project manager and development team. The results show that the proposed method is very useful to identify those activities needing greater allocation of resources, and which of these will have a higher impact on the projects success probability.Therefore using the measure of efficiency has allowed a modular approach to identify those activities in software development on which to focus the project's limited resources to improve its probability of success. The genetic algorithm and the measure of efficiency presented in this paper permit model independence, in both prediction of success and cost evaluation.