International Software Process Association (ISPA)



author(s): Sami Zahran
title: Business and cost justification of software process improvement
organisation(s): Bull Information Systems, Ltd.




Business and cost justification of software process improvement

Abstract

One of the major obstacles for the adoption of software process improvement (SPI) is the reluctance of business management to invest in SPI because they do have convincing evidence of the return on investment. There is a general lack of reliable information on the business benefits of SPI and there is no hard evidence of satisfactory return on investment (ROI) from SPI. This paper presents an approach for preparing a business case with cost-benefit justification for software process improvement. The approach identifies the quantitative elements of cost and benefits which could be easily measured, and suggests an approach to quantify the qualitative benefits. The qualitative benefits are usually harder to include into a cost-benefit justification study, although they may very well turn to provide the most important elements of the return on investment. The transformation of qualitative factors into quantitative factors can be achieved through a risk assessment method which puts a cost for each risk, and the total of these is called a risk budget. The paper argues that using the risk budget for risks attributed to undisciplined process environment could be used as part of the benefits expected out of software process improvement which should lead to disciplined processes, hence minimizing the risks associated with undisciplined processes.

FIGURES

Summary of the Paper

Background & Justification

Many software professionals have difficulty convincing business and financial managers of the positive return on investment for software process improvement. . Not all managers believe in the value or the importance of software process improvement. It is the duty of the software process champions/community to develop, perform and publish hard evidence on the positive ROI for SPI. In order to invest in software process improvement, business managers need convincing of the benefits in hard terms of investing in SPI. The process maturity movement needs more success stories and hard evidence for the benefits of SPI effort. An effort needs to be done in developing and suggesting common normalised guidelines for preparing cost-benefit justification and for calculating the ROI on SPI. This paper is offered as a contribution to this effort. When evaluating or predicting the ROI as part of preparing cost/benefit justification for the SPI, it is important that we consider quantitative benefits, such as increased quality and increased productivity, as well as qualitative (or non quantitative) measures such as increased customer satisfaction and improved staff morale. One important aspect that is missing from most ROI studies, is taking into consideration the damage or loss that could be caused by undisciplined process. This paper suggests that such factors should be taken into consideration This could take the form of organisations and projects assessing the risk of staying the way they are "i.e. without improving their software process". This is the other side of the coin of ROI. On the return side, an important aspect that is missing from most of the ROI published papers is assessing or predicting the future business opportunities that an improved process could bring to the organisation.

A Model for SPI Cost-Benefit Justification

This paper suggests an approach and a model that could be used for the cost-benefit justification of SPI. The model lists the main cost elements of establishing an SPI environment and the benefit elements that could be expected of a disciplined process. The elements discussed cover both the elements which can be quantitatively measured as well as those which are mainly qualitative in nature. Most of the work and papers published on ROI from SPI focus on quantitative cost, while coming short of providing a clear method of addressing the qualitative benefits of SPI. This paper suggests an approach of converting qualitative benefits in to quantitative components that can be added to the benefit side of cost-benefit justification when preparing the business case for software process improvement. The quantitative cost component for SPI cover the cost for establishing an SPI infrastructure, such as the organisational roles and responsibilities as well as technical infrastructure to support the process improvement activities. Qualitative cost that can be attributed to the existing undisciplined processes include all the cost associated with producing non-quality products, which could lead to customer dissatisfaction and loss of future business. Examples of the types of such cost are customer dissatisfaction, cost of correcting defects, and cost of rework, and cost of lost business due to non-compliance. Using a suitable risk assessment methodology could help to convert the qualitative factors into quantitative cost. This is achievable through assessing the risk associated with each of the different factors, then allocating a risk budget to each. The risk budget is the cost of mitigating the risk multiplied by the probability of the risk materialising. The risk budget should be added to the potential SPI benefits likely to materialise as a result of improving the processes. The SPI benefits model suggested in the paper lists the classes of benefits that should be expected out of improvements in the software process. The benefits cover those directly resulting from establishing a disciplined software process as well as those resulting from the improvement in the software product quality and the associated customer satisfaction. Examples of the sources of quantifiable benefits include: increasing productivity, reducing cycle time and reducing development and maintenance cost. Examples f non-quantifiable benefits include improving the level of customer services, improving the requirements change control, and reducing the maintenance effort. Such qualitative benefits can be converted into quantitative benefits through the risk qualification and quantification methodology.

Need for a Unified Cost-Benefit Model

As Watts Humphrey states "process improvement is a journey, and not a destination". This view should be adopted when we try to postulate on the return on investment in software process improvement. This paper uses a model for software process improvement environment as the basis for identifying the cost elements on establishing an SPI programme. Using a unified model by different organisations has the benefit of brining comparable results and making benchmarking across organisations a possibility. Another benefit of such a model is to provide guidelines and a baseline for organisations to start a metrics programme associated with SPI effort. Need for more published ROI case studies, which illustrates in hard terms the business benefits which resulted form investment in SPI. To come with such an evidence an organisation needs to have gone through at least one complete improvement cycle. Average time for a complete SPI cycle is between 18 months and 36 months. That is why only few organisations have completed such cycle. These are the pioneer organisations, such as Hughes aircraft and Raytheon, who started SPI efforts in the early stages of the process maturity movement in the late 1980's early 1990's and completed at least one full cycle of SPI. So far, it seems that, every organisation follows its own approach to measuring the benefits of SPI. In the meantime there are no common or standard models for performing cost-benefit justification of SPI. While it is easy to handle cost-benefit justification In terms of the quantifiable components of cost and benefit, there is difficulty in tackling the qualitative aspects of cost and benefit.

An Example: Cost-Benefit Justification for moving from Level 1 to Level 2 of the CMM

Assume that we need to justify to the business management that we need to invest into software process improvement to move the organisation's software process to level 2 of the CMM. Level 2 of the CMM implies a disciplined process, and requires the establishment of six key process areas. These are requirements management, project planning, project tracking, subcontractor management, quality assurance and configuration management. The example contrasts a project without these key processes in place (Level 1 of the CMM) with one which has all these processes in place (Level 2 of the Capability Maturity Model) as illustrated in figure 1. To appreciate this, let us consider the aspects that we should address if we try to justify investing into moving to a disciplined process, what is meant by these qualitative aspects, try thinking about these questions:

Risk Budget as SPI Benefits

In order to do justice to the cost-benefit justification of SPI, we need to quantify the potential benefits of improvements in these areas. One way to achieve this is to follow a risk assessment methodology which qualifies then quantifies the project risk. An example of such a methodology is known as PRAM "Project Risk Analysis and Management" which is used by a number of European companies to identify, analyse and mitigate the risk associated with systems integration projects. The PRAM risk management model has the following phases which are applied to the critical processes identified and iterated continuously throughout the project's development:

One of the core concepts of PRAM methodology is the concept of a risk budget. The risk budget is the total of the mitigated risk value, that is the mitigated risk impact cost multiplied by the mitigated risk probability. The value of this budget is the value that should be added to the potential benefit of SPI when preparing an cost-benefit justification for SPI.

SPI Costing Model

The paper also provides guidelines for identifying and measuring the cost elements incurred while establishing an SPI environment. The costing model identifies the four major components of an SPI environment and lists the main cost components of each. The four components are: the SPI Infrastructure, SPI Roadmap, SPI Assessment, and SPI Improvement Plan. The paper gives examples and guidelines of working out the cost and benefits associated with each of these components. Both direct and indirect elements of the costs and benefits are discussed in the paper, as well as the quantitative and qualitative elements. One approach to develop a cost-benefit justification for SPI investment, is to define and declare some key indicators that will be tracked and measured for the project or number of projects before and after the SPI. These indicators could take the form of Key Quality Indicators (KQI's) consistent with those that may have been defined as part of a TQM programme for the business. They could also take the form of key performance indicators (KPI's) that is agreed with the project managers and project staff. Other indicators could be other project health indicators (PHI's) that are agreed at the project planning stage, and are reviewed regularly in the project tracking events. Examples of KQI's, KPI's, and PHI's are illustrated in the paper.

Table of Contents



ISPA Homepage - This information last updated October 1997
Copyright © 1996-7. All rights reserved.