Distributed software development in a financial services organisation

The outsourcing of IS functionality to offshore development firms has been a growth industry that has blossomed over the last 10 years. This is as a result of organisations, seeking to optimise costs, mitigate risks, and achieve greater return on shareholder value by delegating the delivery of business information systems and applications to third party vendors. At the same time, distributed approaches to software development has arisen, there has been a growing interest in the applicability of lightweight or Agile development methodologies. As such, this paper this paper discusses experiences of a European Financial Services firm in outsourcing, and subsequently offshoring, two of its IT projects to vendor firms in India, where Agile approaches were used. The authors provide a model of the financial firm’s critical success factors presented as a frame of reference for others interested and involved in this topical area

Is project management the new management 2.0?

This paper considers the evolving nature of project management (PM) and offers a comparison with the evolving nature of management generally. Specifically, we identify a number of management trends that are drawn from a paper that documents a proposed ‘Management 2.0’ model, and we compare those trends to the way in which PM is maturing to embrace the challenges of modern organizational progress.Some theoretical frameworks are offered that assist in explaining the shift from the historically accepted ‘tools and techniques’ model to a more nuanced and behaviorally driven paradigm that is arguably more appropriate to manage change in today’s flexible and progressive organizations, and which provide a more coherent response, both in PM and traditional management, to McDonald’s forces. In addition, we offer a number of examples to robustly support our assertions, based around the development of innovative products from Apple Inc. In using this metaphor to demonstrate the evolution of project-based work, we link PM with innovation and new product development.

How Do Real Options Concepts Fit in Agile Requirements Engineering?

Agile requirements engineering is driven by creating business value for the client and heavily involves the client in decision-making under uncertainty. Real option thinking seems to be suitable in supporting the client’s decision making process at inter-iteration time. This paper investigates the fit between real option thinking and agile requirements engineering. We first look into previously published experiences in the agile software engineering literature to identify (i) ‘experience clusters’ suggesting the ways in which real option concepts fit into the agile requirements process and (ii) ‘experience gaps’ and under-researched agile requirements decision-making topics which require further empirical studies. Furthermore, we conducted a cross-case study in eight agile development organizations and interviewed 11 practitioners about their decision-making process. The results suggest that options are almost always identified, reasoned about and acted upon. They are not expressed in quantitative terms, however, they are instead explicitly or implicitly taken\ud into account during the decision-making process at interiteration time

Boundary Objects and their Use in Agile Systems Engineering

Agile methods are increasingly introduced in automotive companies in the attempt to become more efficient and flexible in the system development. The adoption of agile practices influences communication between stakeholders, but also makes companies rethink the management of artifacts and documentation like requirements, safety compliance documents, and architecture models. Practitioners aim to reduce irrelevant documentation, but face a lack of guidance to determine what artifacts are needed and how they should be managed. This paper presents artifacts, challenges, guidelines, and practices for the continuous management of systems engineering artifacts in automotive based on a theoretical and empirical understanding of the topic. In collaboration with 53 practitioners from six automotive companies, we conducted a design-science study involving interviews, a questionnaire, focus groups, and practical data analysis of a systems engineering tool. The guidelines suggest the distinction between artifacts that are shared among different actors in a company (boundary objects) and those that are used within a team (locally relevant artifacts). We propose an analysis approach to identify boundary objects and three practices to manage systems engineering artifacts in industry

XP customer practices: A grounded theory

The Customer is a critical role in XP, but almost all XP practices are presented for developers by developers. While XP calls for Real Customer Involvement, it does not explain what XP Customers should do, nor how they should do it. Using Grounded Theory, we discovered eight customer practices used by successful XP teams: Customer Boot Camp, Customer’s Apprentice, Customer Pairing, and Programmer’s Holiday support the well-being and effectiveness of customers; Programmer On-site and Road shows support team and organization interactions; and Big Picture Up Front and Re-calibration support Customers steering the whole project. By adopting these processes, XP Customers and teams can work faster and more sustainably

Complementing Measurements and Real Options Concepts to Support Inter-iteration Decision-Making in Agile Projects

Agile software projects are characterized by iterative and incremental development, accommodation of changes and active customer participation. The process is driven by creating business value for the client, assuming that the client (i) is aware of it, and (ii) is capable to estimate the business value, associated with the separate features of the system to be implemented. This paper is focused on the complementary use of measurement techniques and concepts of real-option-analysis to assist clients in assessing and comparing alternative sets of requirements. Our overall objective is to provide systematic support to clients for the decision-making process on what to implement in each iteration. The design of our approach is justified by using empirical data, published earlier by other authors