Darren Dalcher

The Dynamics of Collaboration in Multipartner Projects

In many project-based industries, there has recently been an increased tendency for collaboration and cocreation of value with the customers. However, many existing studies report inherent challenges and complexities related to multipartner collaboration. This article presents a conceptual framework that explains the focal collaboration-related elements and their interdependencies in multipartner projects. The elements in the framework and relations between them are derived from the existing empirical studies and theoretical literature on collaboration, knowledge integration, and project success. Based on the conceptual analysis of the extant literature, we identify eight collaboration antecedents and three collaboration outcome elements. The conceptual framework explains how two collaboration mediators, project-collaboration quality and knowledge-integration capability, relate collaboration antecedents with collaboration outcomes. In addition, based on the literature analysis, we identify 15 mechanisms that enhance the project-collaboration quality in multipartner projects. The article provides novel insights on the dynamics of collaboration in multipartner projects by offering the concepts of project-collaboration quality and knowledge-integration capability and explaining their role in collaborative projects.

Developing knowledge management capabilities: a structured approach

Purpose – Knowledge management (KM) needs a systematic approach to develop capabilities which accelerate the evolution of knowledge into a key organizational resource. This paper aims to address this issue.Design/methodology/approach – This paper reports the empirical findings of a case study offering insights into the infrastructure and process capabilities required to provide knowledge support for organizational routines and activities.Findings – It also presents a four‐stage framework that helps to make sense of the development of capabilities during the implementation of KM initiatives.Practical implications – The research moves KM capability development from being a mere concept to being a clearly articulated set of stages, which underpin organizational growth.Originality/value – As above, the research moves KM capability development from being a mere concept to being a clearly articulated set of stages, which underpin organizational growth.

COCOMO-Based Effort Estimation for Iterative and Incremental Software Development

Incremental software development and delivery have been used in software projects in many ways for many years. Justifications for incremental approaches include risk amelioration, the management of evolving requirements, and end-user involvement. Incremental development, including iterative, incremental delivery, has become a norm in many sectors. However, there has been little work on modelling the effort in such development and hence a dearth of comparative analyses of cost models for incremental development/delivery. We attempt to rectify this by proposing a COCOMO-style effort model for incremental development/delivery and explore the relationship between effort and the number of increments, thereby providing new insights into the economic impact of incremental approaches to software projects.

Comparison of software development life cycles: a multiproject experiment

A variety of life cycle models for software development are generally available. Many of the variations were composed to overcome problems in the classic waterfall model. However, it is generally difficult to compare and contrast the methods and very little literature is available to guide developers and managers in making choices. Moreover, in order to make informed decisions, developers require access to real data that compares the different models and the results associated with the adoption of each model. An experiment in which 15 software teams developed comparable software products, using four different development approaches (V-model, incremental model, evolutionary model, and extreme programming), is described. Extensive measurements were taken to assess the time, quality, size, and development efficiency of each product. The experimental data collected and the conclusions related to the choice of method, its impact on the project and the quality of the results, are presented.

Learning from Failures

This paper addresses the topic of failures in computer-based systems. It does so in three stages: first it describes failure cases in a single domain, that of computer-based ambulance despatch systems; then it discusses some of the features of those cases; finally it considers the importance of reporting and analysing failures, in order to discover their causes and to learn lessons that will help eliminate those causes of failure in the future. Failure, it is argued, provides a valuable learning opportunity that may lead, when recognized, to better practice and future success. Copyright

Effort Estimation in Incremental Software Development

Incremental software development offers many benefits compared with more traditional development approaches. Indeed, incremental approaches have been utilised for many years due to the involvement of users, the early demonstration of capability and the potential for risk reduction that they offer. However, there appears to have been little work on modelling, planning and controlling incremental development. The paper attempts to introduce a quantitative analytical framework for evaluating such approaches and their impacts on the development effort. Models that predict development effort as an exponential function of product size are used in the paper to explore some of the relationships between effort and the number of increments, thereby providing new insights into the economic impact of incremental approaches to software projects.

Development life cycle management: a multiproject experiment

A variety of life cycle models for software systems development are generally available. However, it is generally difficult to compare and contrast the methods and very little literature is available to guide developers and managers in making choices. Moreover in order to make informed decisions developers require access to real data that compares the different models and the results associated with the adoption of each model. This paper describes an experiment in which fifteen software teams developed comparable software products using four different development approaches (V-model, incremental, evolutionary and extreme programming). Extensive measurements were taken to assess the time, quality, size, and development efficiency of each product. The paper presents the experimental data collected and the conclusions related to the choice of method, its impact on the project and the quality of the results as well as the general implications to the practice of systems engineering project management.

Introduction: Avoiding IS/IT Implementation Failure

Software failures have a habit of making the news: the more spectacular the failure, the larger the headline. While the front pages of the professional computing journals are normally reserved for such stories, failure stories also have a tendency of making national and even international headlines. The statistics on information systems/information technology (IS/IT) failure are quite telling. Current estimates suggest that the annual cost of IS failures in Western Europe adds up to US

Beyond normal failures : Dynamic management of software projects

140 billion, while the USA is reckoned to lose US

Why the pilot cannot be blamed: a cautionary note about excessive reliance on technology

150 billion in any given year. With such alarming figures, individual failure stories are often compared to tips of icebergs, thus representing but a mere fraction of the true scale of the problem. One recent example of a high profile implementation failure is related to the troubled Libra project in the UK. 1 Libra was designed to provide a standard IT system for magistrates’ courts including upgraded infrastructure, office automation facilities, a national casework application and electronic links with other criminal justice agencies. The original contract for £184 million was awarded in 1998 but following implementation problems the deal collapsed in July 2002. Following re-negotiation later in 2002, the infrastructure portion alone cost £232 million. The total system would now take 8.5 years to develop and cost over £318 million. The chairman of the House of Commons’ Public Accounts Committee, Edward Leigh, described the system as one of the worst IT projects he had come across, especially as it was likely to cost more than twice the original estimate and would now be available (to deliver benefit) for two years less than anticipated. From a purely economic perspective, a product (or an IT system) will be deemed successful if the returns on any investment needed exceed the costs of development as well as any other limitations that may ensue during or following the development effort. The cost is primarily determined by the finance expended on development. However, delay to the utilization of some of the benefits can also count as a cost. The utility derived from a system encapsulates the perceived returns generated by the system and its usage. Failures can be quantified in different ways, however, so that money wasted on a project is not the only criterion that defines ‘cost’. Certain projects are likely to have an impact beyond the initially predicted boundaries, and may even lead to losses elsewhere within the system. Another recent disaster in the UK, related to an earlier implementation failure concerns the delay in introducing the Nirs2 system into the Inland Revenue beginning in 1995. This resulted in backlogs that caused the Inland Revenue to stop sending reminders to up to a third of the UK working force warning them that they