Skip to main content

Über dieses Buch

By bringing together various current direc­tions, Software Project Management in a Changing World focuses on how people and organizations can make their processes more change-adaptive. The selected chapters closely correspond to the project management knowledge areas introduced by the Project Management Body of Knowledge, including its extension for managing software projects.

The contributions are grouped into four parts, preceded by a general introduction. Part I “Fundamentals” provides in-depth insights into fundamental topics including resource allocation, cost estimation and risk management. Part II “Supporting Areas” presents recent experiences and results related to the management of quality systems, knowledge, product portfolios and glob­al and virtual software teams. Part III “New Paradigms” details new and evolving software-development practices including agile, distributed and open and inner-source development. Finally, Part IV “Emerging Techniques” introduces search-based tech­niques, social media, software process simulation and the efficient use of empirical data and their effects on software-management practices.

This book will attract readers from both academia and practice with its excellent balance between new findings and experience of their usage in new contexts. Whenever appropriate, the presentation is based on evidence from empirical evaluation of the proposed approaches. For researchers and graduate students, it presents some of the latest methods and techniques to accommodate new challenges facing the discipline. For professionals, it serves as a source of inspiration for refining their project-management skills in new areas.



Chapter 1. Software Project Management: Setting the Context

This chapter is designed as the introduction to the book. It provides the motivation for studying software project management as a response to the increasing variety of software development methodologies. The chapter characterizes software projects and presents ten knowledge areas in software project management. This body of knowledge is described in the software edition of the Project Management Body of Knowledge (PMBOK). The chapters of the book are classified in terms of their contribution to these knowledge areas.
The chapter also discusses the multidisciplinary nature of the project management discipline. Based on some predicted trends for the future of software engineering, a prediction on the future of software project management is given. Finally, an overview of the content and structure of the whole book is presented.
Günther Ruhe, Claes Wohlin



Chapter 2. Rethinking Success in Software Projects: Looking Beyond the Failure Factors

The notions of success and failure in software projects are confusing. Failure is often considered in the context of the iron triangle as the inability to meet time, cost, and performance constraints. While there is a consensus around the prevalence of project failure, new projects seem destined to repeat past mistakes. This chapter tries to advance the discussion by offering a new perspective for reasoning about the meaning of success and the different types of software project failures.
In order to court project success, practitioners need to rise beyond a fixation with the internal parameters of efficiency, thus bringing forth the effectiveness required to secure project success. The chapter begins by discussing the limited insights from existing project failure surveys, before offering a four-level model addressing the essence of successful delivery and operation in software projects. Following consideration of outcomes and time, the chapter offers a series of vignettes and mini case studies that highlight the rich interplay between the four levels of success, before addressing the types of measures underpinning the four levels and the need to develop a multi-dimensional perspective to obtain a more accurate picture regarding the success of a project.
Darren Dalcher

Chapter 3. Cost Prediction and Software Project Management

This chapter reviews the background and extent of the software project cost prediction problem. Given the importance of the topic, there has been a great deal of research activity over the past 40 years, most of which has focused on developing formal cost prediction systems. The problem is that presently there is limited evidence to suggest formal methods outperform experts, therefore detailed consideration is given to the available empirical evidence concerning expert performance. This shows that software professionals tend to be biased (optimistic) and over-confident, and there are a number of deep cognitive biases which help us understand why this is so. Finally, the chapter describes how this might best be tackled through a range of simple, practical and evidence-based methods.
Martin Shepperd

Chapter 4. Human Resource Allocation and Scheduling for Software Project Management

Software project management consists of a number of planning, organizing, staffing, directing and controlling activities. Human resources feature prominently in all of these activities and, as a consequence, they can affect and determine project management decisions. Therefore, in order to help guarantee the success of a software project, managers must take into consideration this type of resource when performing the aforementioned activities. This chapter specifically investigates human resources from a planning perspective and, in particular, focuses on the responsibilities of allocating developers and teams to project tasks, scheduling developers and teams, as well as forming development teams. These responsibilities are often challenging to undertake because they are accompanied by time, budget and quality constraints, which software project managers find difficult to balance correctly. The purpose of the chapter is to explore the most recent research work in the field of human resource allocation and scheduling, and to specifically examine the motivation behind each approach and the goals and benefits to real-world practitioners. In addition, the chapter investigates development team formation, which can be considered as an indirect method of allocating human resources to a software project. This perspective, in particular, sheds light on current and future trends, which lean towards incorporating human-centric aspects of software development in planning activities.
Constantinos Stylianou, Andreas S. Andreou

Chapter 5. Software Project Risk and Opportunity Management

Risk is an uncertain event or condition that has a positive or negative effect on project objectives. Risk management includes the processes of planning, identification, analysis, resource planning, and controlling risk in a project. This chapter focuses on recent insights and approaches within risk management. A positive counterpart to risk management has emerged, called opportunity management. The duality between the two concepts is explained, and the fundamentals of risk–opportunity management are discussed. Furthermore, risk and opportunity management methods, processes, and tools are presented.
Barry Boehm

Supporting Areas


Chapter 6. Model-Based Quality Management of Software Development Projects

Managing the quality of artifacts created during the development process is an integral part of software project management. Software quality models capture the knowledge and experience regarding the quality characteristics of interest, the measurement data that can help to reason about them, and the mechanisms to use for characterizing and assessing software quality. They are the foundation for managing software quality in projects in an evidence-based manner. Nowadays, coming up with suitable quality models for an organization is still a challenging endeavor. This chapter deals with the definition and usage of software quality models for managing software development projects and discusses different challenges and solutions in this area. The challenges are: (1) There is no universal model that can be applied in every environment because quality is heavily dependent on the application context. In practice and research, a variety of different quality models exists. Finding the “right” model requires a clear picture of the goals that should be obtained from using the model. (2) Quality models need to be tailored to company specifics and supported by corresponding tools. Existing standards (such as the ISO/IEC 25000 series) are often too generic and hard to fully implement in an organization. (3) Practitioners require a comprehensive set of techniques, methods, and tools for systematically specifying, adapting, and applying quality models in practice. (4) In order to create sustainable quality models, their contribution to the organizational goals must be clarified, and the models need to be integrated into the development and decision-making processes.
Jens Heidrich, Dieter Rombach, Michael Kläs

Chapter 7. Supporting Project Management Through Integrated Management of System and Project Knowledge

Software engineering is a knowledge-intensive task. Many different kinds of knowledge are created, for example, system knowledge, such as requirements, design, or code, and project knowledge, such as project plans, decisions, and work items. In this chapter, we study two kinds of project knowledge: work items and decisions. Work items document what should or has been done by whom and when. Decisions represent the solution to a decision problem. They are important to be kept in mind so that the future development will be consistent with the past. These kinds of knowledge can be implicit or explicit. Work items are typically managed explicitly in issue trackers, while decisions are mostly hidden in informal notes or in the artifacts, which result from these decisions. Rationale management research has suggested several approaches to make decisions and their rationale explicit. However, in contrast to issue trackers, which are widespread, these approaches are considered as overhead in industry. In this chapter, we argue that work items and decisions should be managed together with the system knowledge. This has several benefits for project management processes, such as project planning or monitoring, for example, with better information for the allocation of work items or risk identification. We present a vision detailing these benefits and discuss what is known in research and practice about the realization of this vision. In particular, we review existing approaches to capture work items or decisions and their links to other knowledge and discuss the empirical evidence of their benefits for an integrated system and project knowledge management in industry.
Barbara Paech, Alexander Delater, Tom-Michael Hesse

Chapter 8. Framework for Implementing Product Portfolio Management in Software Business

Whether a software product company takes up a project depends on the strategic decisions that are made with regard to an organization’s products. A software project needs to fit strategic goals and enable an organization to realize a vision through its software products. Making decisions on a strategic level, however, requires information of several related topics including technological trends and the product’s life cycle and surpasses the scope of an individual software project. Instead, these decisions are made on the level of the product portfolio. Product Portfolio Management (PPM) holds that an organization has to manage investment decisions over time following profit and risk criteria. Given the multitude of relevant topics and the interrelatedness between these topics, it has proven difficult to implement PPM processes in software businesses. To this end, we created the Portfolio Implementation Framework (PIF) consisting of (a) a competence model, giving an overview of the critical topics; (b) process-deliverable diagrams, which provide an implementation path for product portfolio management processes; and (c) a maturity matrix that comprises 32 capabilities, which should be realized during implementation. The maturity matrix also serves as an instrument for industry to assess, compare and improve portfolio management processes across organizations. The framework provides a holistic view on a step-by-step PPM process implementation and has proved its applicability in practice.
Erik Jagroep, Inge van de Weerd, Sjaak Brinkkemper, Ton Dobbe

Chapter 9. Managing Global Software Projects

Projects are increasingly distributed across different sites. But distributed teams and suppliers complicate communication and create numerous frictions. Over half of all distributed projects do not achieve their intended objectives and are then canceled. Traditional labor cost-based location decisions are replaced by a systematic improvement of business processes in a distributed context. Benefits are tangible, as our clients emphasize: better multisite collaboration, clear supplier agreements, and transparent interfaces are the most often reported benefits. There is a simple rule: Only those who professionally manage their distributed projects will succeed in the future.
This chapter summarizes experiences and guidances from industry in a way to facilitate knowledge and technology transfer. It looks to processes and approaches for successfully handling global software development and outsourcing and offers many practical hints and concrete explanations to make global software engineering (GSE) a success. Starting with the necessary foundations, the chapter indicates what solutions are available to successfully implement GSE. It underlines the basic concepts and practices of GSE with broad industrial experiences and also summarizes future trends in GSE. The chapter is based on an industry perspective taking into consideration the state of the practice to ensure direct transfer and applicability to distributed projects.
Christof Ebert

Chapter 10. Motivating Software Engineers Working in Virtual Teams Across the Globe

The motivation of software engineers affects the quality of the software they produce. Motivation can be viewed in terms of needs. The key need for a software engineer is to ‘identify with their task’ which requires being given a task that is challenging and understanding the purpose and significance of the task in relation to the complete system being developed. Software engineers’ needs are complex – they also require regular feedback, trust, appreciation, rewards, a career path, and sustainable working hours. Furthermore, amongst other fixed environmental factors, these motivators require sensitive tuning in line with a software engineer’s personality and career stage. Creating this personality-job fit is not easy in a co-located environment, so how can project managers motivate teams of individuals distributed across the globe?
This chapter reflects on some of the motivational issues that managers of virtual teams may encounter. Some background theory is presented for a deeper understanding of how to manage team motivation. Recommendations are drawn from a case study where issues raised by practitioners working in virtual teams serve to highlight and magnify known motivational issues. Project managers play an important part in software engineer motivation. If they can create a working environment that motivates individuals in the team, they will find that team members are more likely to turn up to work, are less likely to look elsewhere for employment, will work harder to meet deadlines, will take more pride in their work, and will share their knowledge, concerns, and ideas for innovation.
Sarah Beecham

New Paradigms


Chapter 11. Agile Project Management

Agile software development represents a new approach for planning and managing software projects. It puts less emphasis on up-front plans and strict control and relies more on informal collaboration, coordination, and learning. This chapter provides a characterization and definition of agile project management based on extensive studies of industrial projects. It explains the circumstances behind the change from traditional management with its focus on direct supervision and standardization of work processes, to the newer, agile focus on self-managing teams, including its opportunities and benefits, but also its complexity and challenges. The main contribution of the chapter is the four principles of agile project management: minimum critical specification, autonomous teams, redundancy, and feedback and learning.
Tore Dybå, Torgeir Dingsøyr, Nils Brede Moe

Chapter 12. Distributed Project Management

Ten Misconceptions That Might Kill Your Distributed Project
This chapter is dedicated to companies engaged in collaborative software projects with staff distributed across several locations. The chapter is organized around ten problem areas. Each problem area starts with a common misconception, followed by a discussion of complexities associated with distributed development as opposed to co-located development, practices known for addressing these complexities, and a short list of implications for practice. The aim is to illuminate the key complexities of managing distributed development projects. While project managers in co-located projects are equipped with tools, practices, and methods, these are often of little help when dealing with the challenges of distributed environment. Hence, inexperienced managers often fail to foresee and proactively address the common problems. The readers will learn to distinguish different types of distributed projects (including onshoring, offshoring, outsourcing, and insourcing, to name a few) and challenges, both context dependent and common for distributed projects.
Darja Šmite

Chapter 13. Management and Coordination of Free/Open Source Projects

Developing software in the free/open source software (F/OSS) way is fundamentally different from the conventional, closed, team-based, single-owner software project. As a consequence, managing a F/OSS project is done in a quite different way, emphasizing on people and community coordination and organization. Management organization may take extremely distant forms: absolute monarchies, oligarchies, or open source democracies, with community members voting to decide project evolution. On the other hand, not all F/OSS projects are based on pure voluntarism. Many such projects are sponsored by firms and are managed in their own way. In addition, certain extreme project transformations, such as forking, occur frequently in F/OSS. Human resource management (e.g., team building) and decision making (e.g., project cancellation) are also done in a completely different way. This chapter focuses on how human resource management and project organization are handled in F/OSS today. On the other hand, there are several areas in which, given enough research and experimentation, new tools may be provided to assist informed, successful F/OSS management, aiming to help both experienced and novice F/OSS coordinators. The chapter attempts to foresee how measurement, simulation, and antipattern techniques might help F/OSS managers in the future.
Ioannis Stamelos

Chapter 14. Inner Source Project Management

Software development organizations are continuously looking for better ways to manage their projects. An emerging approach to achieve this is Inner Source, which refers to the adoption of Open Source development practices within the confines of an organization. With an Inner Source approach, individuals, teams, and departments within an organization can start software projects, very similar to the Open Source model. This affects the way projects are managed in a variety of ways. Firstly, it will affect strategic aspects such as a software sourcing strategy that includes decisions on which software can be “Inner-Sourced.” Secondly, at the tactical level, organizations should choose an appropriate Inner Source adoption model that suits the goals and scope of the organization. Finally, it will affect the operational aspects of a project, for example, in the way different people across a whole organization can access the source code and make improvements. Furthermore, Inner Source makes communication much more transparent. While Inner Source offers a variety of potential benefits to an organization, there are also a number of challenges to address. This chapter discusses how the introduction of Inner Source may affect conventional software developing environments and especially how it affects software project management aspects. Based on our studies and those presented in the literature, it outlines a number of benefits of Inner Source as well as a number of challenges and some suggestions as to how they can be addressed.
Martin Höst, Klaas-Jan Stol, Alma Oručević-Alagić

Emerging Techniques


Chapter 15. Search-Based Software Project Management

Project management presents the manager with a complex set of related optimisation problems. Decisions made can more profoundly affect the outcome of a project than any other activity. In the chapter, we provide an overview of Search-Based Software Project Management, in which search-based software engineering (SBSE) is applied to problems in software project management. We show how SBSE has been used to attack the problems of staffing, scheduling, risk, and effort estimation. SBSE can help to solve the optimisation problems the manager faces, but it can also yield insight. SBSE therefore provides both decision making and decision support. We provide a comprehensive survey of search-based software project management and give directions for the development of this subfield of SBSE.
Filomena Ferrucci, Mark Harman, Federica Sarro

Chapter 16. Social Media Collaboration in Software Projects

Social media has had a big impact on the way that software projects are managed and the way that stakeholders interact with each other: indeed, the nature of software projects has evolved substantially in keeping with the evolution of technology. A direct consequence of the ubiquity of the Internet is the increasing trend toward cooperation outside the boundaries of an office. The interactions involved in software projects have changed accordingly and can be broadly divided into two types: (1) interactions among stakeholders who are in a single location (e.g., people sharing the same office space) and (2) interactions among stakeholders who are in distributed locations (e.g., software projects that are partly implemented offshore). Social media has been and remains a significant facilitator to these kinds of interactions. This chapter looks at the implications of the use of social media software projects in today’s changing world.
Rachel Harrison, Varsha Veerappa

Chapter 17. Process Simulation: A Tool for Software Project Managers?

Process simulation has been introduced as a tool in support of software project management more than 25 years ago. Since then, it has been considered an approach with high potential for making software project managers’ work more effective and successful. Unfortunately, despite high expectations and many reports on prototypical process simulation applications in industrial contexts, little evidence exists that process simulation has become an accepted and regularly used tool of software project managers. This chapter investigates the reasons for lacking impact of process simulation in the software industry. This is done with the help of an in-depth description of a software process simulation application example. The application example focuses on the effects of various workforce allocation strategies on project performance, expressed in terms of project duration, effort consumption, and product quality. With the help of the application example and based on existing literature, the gap between the current state of the art of software process simulation and the actual state of practice is described and its root-causes are discussed. The chapter concludes with a list of issues that need to be addressed in order to close the gap between the state of the art and the state of practice. Most of the issues relate to the difficulty of demonstrating a positive cost-benefit ratio when applying process simulation as a tool in support of software project management tasks.
Dietmar Pfahl

Chapter 18. Occam’s Razor and Simple Software Project Management

Occam’s Razor is a principle of parsimony for problem solving. It states that among competing hypotheses, the one with the fewest assumptions should be selected. This chapter applies Occam’s Razor to model-based project management. In this style of management, a manager uses models to guide their decisions. Ideally, such models should be supported by empirical data.
This chapter explores the limits to building models from data. Results from AI and data mining show that most data sets support only very simple models. For such data, some minimal modeling (supported by automatic tools) will produce models as good as anything else.
Automatic tools can exploit this “minimal models” effect. Such tools can automatically find very simple and very succinct recommendations about how to change and improve software projects.
Tim Menzies


Weitere Informationen

Premium Partner