Software project control and metrics

2009

Software Project Management has always been considered as a Herculean task for organizations and enterprises with limited or insufficient technical expertise and resources. The difference contradiction between business and engineering conceptions on project definition, management and success, resulted in project failures and catastrophic technological investments and business initiatives. This paper aims to contribute in software project management by identifying a new innovative measurement unit based on which software projects can obtain a volume that will be used throughout a project tracking process integrating business and engineering goals and objectives under a common project success perception. This new project tracking approach can assure financial and operational benefits by minimizing the lack of communication between business and engineering parties involved in the implementation of a software oriented investment or business initiative.

2007

In this paper we present an empirical study on factors that cause the success or failure of a software project. The study deals with the definition and validation of metrics and indicators to make more objective the meaning of success (and conversely failure) of a project, and correlates characteristics of a project (such as experience of the staff and the project manager, techniques used for requirement engineering, and so on) with its result. The study, performed on a number of Italian companies, can be easily replicated in other countries or within a company, in order to assess its software processes and steer its process improvement initiatives.

Software Project Management is a core topic in software engineering courses because it teaches how software projects planned, implemented, controlled, monitored, and evaluated. The development of theories in software metrics and prediction models builds on the broader project management field but also attempt to overcome the difficulties inherent in measuring an intangible object like software. This paper is situated within research into the factors that influence cost and time estimation for software projects that continue to challenge software development organizations. The study described in this paper explored technical and non-technical factors seen by Sudanese software practitioners as critical in estimation, and if not managed, can result in cost and time overrun or in some cases lead to project failure. Using a mixed-method approach, the research project was first informed through a qualitative study that explored the kinds of problems that face the estimation process from the perspectives of different staff levels. This part of the study revealed a number of factors that can be broadly categorized as technical factors, e.g. the skills of those involved in the estimation process, and non-technical factors such as the high level of uncertainty in the local business environment. The second part of the study focused on one of the leading factors, software project staff training and experience, using the survey method to examine how well the software engineering curriculum is aligned with skills required in the software market, especially those related to estimation. The recommendations this study produced on reducing estimation errors, whether geared towards companies or academia, are preliminary and may only reflect the local setting. However, they also drew upon the vast literature on cost estimation techniques and case studies in similar and more advanced settings. The problem of software effort prediction and estimation models has been a thorny issue in the software engineering field since the concept of "software crisis" and the field itself, as a response to the crisis, emerged in the late 1960s. It still seems to some that "After forty years of currency the phrase 'software engineering' still denotes no more than a vague and largely unfulfilled aspiration" [2]. This study develops our understanding of problems facing one of the young professions in the country, as well as contributes to the global body of research on developing techniques to manage the intricacy of software engineering compared to more established engineering disciplines.

2011 Joint Conference of the 21st International Workshop on Software Measurement and the 6th International Conference on Software Process and Product Measurement, 2011

To clarify the characteristics of cost-overrun software projects, this paper focuses on the cost to sales ratio of software development, computed from financial information of a midsize software company in the embedded systems domain, and analyzes the correlation with outsourcing ratio as well as code reuse ratio and relative effort ratio per development phase. As a result, we found that a lower cost to sales ratio projects had the higher relative effort ratio in the external design phase, which indicates that spending less effort on external design can cause decrease of profit. We also found that high outsourcing ratio projects had a higher cost to sales ratio, and that projects having a moderate code reuse ratio had a lower and disperse cost to sales ratio, which suggests that troubles in code reuse can damage the profit of a project.

Eric van der Vliet 45 Abstract Nowadays, Sogeti Nederland gets more and more questions from clients like: "What is your productivity rate for Java projects?", "What is your duration for building an application of 1000 function points?" and "What is your price per function point for a .Net project?" Literature shows us however, that there is no good answer to these kinds of questions. Putnam [1] is one of the people that show us that the amount of effort needed for a project highly depends on the duration chosen. Other factors that influence the answer to these questions might be: size, complexity and the amount of work that is being carried out on an offshore location (like India). It is therefore necessary to consider all the relevant factors when preparing a project estimation. However, if this has to be done on an ad hoc basis (whenever a client asks, or whenever a Request for Proposal comes in), it will take a lot of time to analyze the right projects. To make things faster and easier, Sogeti has developed a tool to estimate projects and to answer questions like the questions mentioned above. In the paper the tool and its underlying principles are introduced and the preliminary results are given.

2000

In Peter W. G. Morris, Jeffrey K. Pinto, and Jonas Söderlund, eds., The Oxford Handbook of Project Management, Oxford: Oxford University Press, pp. 321-344 , 2011

It is useful to distinguish between “causes” and “root causes” in explaining cost overruns, benefit shortfalls, and delays in major projects. Conventionally, the following are listed as causes of project underperformance in the literature: project complexity, scope changes, technological uncertainty, demand uncertainty, unexpected geological features, and negative plurality, i.e. opposing stakeholder voices. No doubt, all of these factors at one time or another contribute to cost overruns and benefit shortfalls, but it may be argued that they are not the real, or root, cause. The root cause of underperformance is the fact that project planners tend to systematically underestimate or even ignore risks of complexity, scope changes, etc. during project development and decision-making. Such ignorance or underestimation of risks is often called optimism, and if we accept this terminology the root cause of underperformance is optimism, whereas complexity, scope, technology, etc. are simply specific issues about which planners have been optimistic and through which optimism therefore manifests itself. Below, the focus will be on root causes of underperformance and not on conventional causes.

International Journal of Project Management, 1999

This paper provides some thoughts about success criteria for IS–IT project management. Cost, time and quality (The Iron Triangle), over the last 50 years have become inextricably linked with measuring the success of project management. This is perhaps not surprising, since over the same period those criteria are usually included in the description of project management. Time and costs are at best, only guesses, calculated at a time when least is known about the project. Quality is a phenomenon, it is an emergent property of peoples different attitudes and beliefs, which often change over the development life-cycle of a project. Why has project management been so reluctant to adopt other criteria in addition to the Iron Triangle, such as stakeholder benefits against which projects can be assessed? This paper proposes a new framework to consider success criteria, The Square Route.

IEEE Software, 2015

Crosstalk, 2004

An analysis of approximately 250 large software projects between 1995 and 2004 shows an interesting pattern. When com-paring large projects that successfully achieved their cost and schedule estimates against those that ran late, were over budget, or were ...