Paula Savolainen

Software engineering projects may fail before they are started: Post-mortem analysis of five cancelled projects

Context: Software project cancellations are often caused by mistakes made during the project, and such cancellations make a strong economic impact. We analyzed five cancelled software engineering projects. One case was an internal product development project of a company that sells products to its customers. The other four cases were different software engineering projects, and outcomes of these projects were planned to be delivered to external customers. Objective: This study reports a post-mortem analysis of five software engineering projects with the aim of providing more knowledge about the reasons for cancellation decisions and the causes behind those reasons. Methods: The research method is case study. A method for a document-based post-mortem analysis was developed and post-mortem analysis was performed. All project documentation was available for analysis. Results: The reasons for the cancellation decisions were well-known ones. In four cases of five, the outcome of the project was to be delivered to an external customer, but in these cases the causes of the cancellation reasons were not found from the normal project documentation. In these cases the cause of the cancellation originated in a phase before the start of the project and therefore the project was doomed before it was started. Conclusion: It is reasonable to suggest that a remarkable portion of project cancellations are due to mistakes made before the project is started in the case of contract-based software engineering projects.

LAPPI: A light‐weight technique to practical process modeling and improvement target identification

Understanding the current state of the software processes and their problem points is important. Without this understanding, software process improvement (SPI) resources may be allocated to less meaningful targets. SPI work can be challenging to initiate especially in small companies where resources and knowledge of SPI are often limited. The aim of the developed technique, LAPPI (A Light‐weight Technique to Practical Process Modeling and Improvement Target Identification), is to provide an easy to use, lightweight tool for process modeling and improvement target identification. The technique provides a suitable method that integrates with various SPI initiatives. The method used in the development of LAPPI is a nonformal variation of constructive research. LAPPI has been incrementally developed in multiple academia‐industry collaboration projects and by industry actors themselves. Our evaluation of the LAPPI technique in 42 studies conducted in 31 companies indicates that the technique is suitable for modeling the current process and identifying the points of improvement in the process. Practical experience shows that LAPPI provides a cost‐effective technique for process modeling and improvement target identification especially in small and medium‐sized enterprises. It is most useful in the diagnosing phase of SPI. It helps the company to understand the current processes and the organizational interactions, and to create a process description baseline. Copyright

SPI with lightweight software process modeling in a small software company

In small growing software companies, it is important to pay attention to software process improvement (SPI) in order to be successful and competitive in both domestic and foreign markets. However, limited resources and lack of knowledge about process culture may hinder the improvement efforts in small companies. In this paper, we present development activities done in a small growing software company in order to establish basis for SPI. Familiarizing to processes and SPI is done by modeling companys processes using a lightweight software process modeling technique. The modeling combined with external consulting provides the company with capability to visualize their processes and to identify the problems in the processes. The improvement activities have been triggered by pointing out the problems. In the presented case, the company has independently implemented quite significant improvements for identified problems by acquiring needed knowledge and by implementing new tools to support workflows.

Reported project management effort, project size, and contract type

The relation between project size and the proportion of project management effort is analyzed.The larger or longer the project, the greater the proportion of project management effort.The type of contract seems to have an impact on the reported amount of project management effort.The analysis implies that there is a pattern of inaccurate reporting of effort data. Literature based hypotheses on the proportion of project management effort are created and tested with reported effort data from 117 projects by software supplier firms. The results support most of the literature based hypotheses, but some of the hypotheses are not supported. The supported hypotheses are the correlations between project management effort, project size, and team size. The unsupported hypotheses are the necessity of spending at least some project management effort on a project, and the insignificance of contract type. The conflict with previous studies and practical experience may be a result from market pressures and skewed reporting. The analysis implies that there is a pattern of inaccurate reporting of effort data and some possible explanations for the pattern are discussed. The results suggest that we do not properly understand the internal dynamics of supplier firms.

What Happens Before a Project Starts?—Project Start-up from the Supplier Perspective

Before an outsourced software project officially begins the contracting or supplier organization has already expended effort. Although project start and start-up effort impact on project success in most cases these are undefined concepts. There are no clear definitions of project start, start-up or the activities that should be completed before project start either in the literature or in practice. Ambiguity around project start sets up risks to the profitability of a project and therefore makes the real success of a project not only uncertain but difficult to measure. A vague project start also makes comparisons between projects and between organizations unreliable. In this paper, we describe a pilot study that reviews project start, project start-up, and project start date, and then investigates what the key activities of the supplier are normally performed by the end of the project start-up phase. We use interviews with software supplier practitioners to define those key activities.

Vague project start makes project success of outsourced software development projects uncertain

A definition of a project success includes at least three criteria: 1) meeting planning goals, 2) customer benefits, and 3) supplier benefits. This study aims to point out the importance of the definition of the project start, the project start date, and what work should be included in the project effort in order to ensure the suppliers benefits. The ambiguity of the project start risks the profitability of the project and therefore makes project success at least from suppliers point of view uncertain. Moreover, vague project start makes it more difficult to compare project management metrics, such as duration and effort, between projects. There is no clear definition for the project start either in literature or practice. Based on interviews, the definitions are provided for project start, project start date, and project start-up effort included in the project.

Improving the Product Documentation Process of a Small Software Company

Documentation is an important part of the software process, even though it is often neglected in software companies. The eternal question is how much documentation is enough. In this article, we present a practical implementation of lightweight product documentation process resulting from SPI efforts in a small company. Small companies’ financial and human resources are often limited. The documentation process described here, offers a template for creating adequate documentation consuming minimal amount of resources. The key element of the documentation process is an open source web-based bugtracking system that was customized to be used as a documentation tool. The use of the tool enables iterative and well structured documentation. The solution best serves the needs of a small company with off-the-shelf software products and striving for SPI.

Outsourcing through Combining Software Departments of Several Companies

The different types of outsourcing have emerged during the latest few years. The most common types of those cases and their features have been documented and analysed fairly well. In this paper a specific type of outsourcing through combining software departments of several companies is documented and analysed. The analysed case differs from the more commonly analysed cases and therefore adds an interesting point of view to the general knowledge of outsourcing and the possible pitfalls associated with outsourcing activities.

Suppliers’ software development project start-up practices

Purpose 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. Design/methodology/approach 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. Findings 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. Research limitations/implications 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. Practical implications 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. Originality/value 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.

The Presence of the Customer and the Supplier Perspectives in Studies on Software Development Project Success

The Presence of the Customer and the Supplier Perspectives in Studies on Software Development Project Success A systematic literature review on software development project success/failure from customers or suppliers perspective is presented. The review covers studies published in peer-reviewed journals only. The results show that knowledge on software development project success/failure is multidisciplinary and fragmented. In addition, there are very few studies that consider software development project success from the suppliers perspective. One of the main contributions of this article is the table of articles in which articles have been classified by the perspective which they discuss. Another contribution is the list of journals in which the accepted articles have been published. Moreover, these results show a clear lack in our understanding of software development project success in outsourcing situations.