Ever since information technology era began, software quality has been an ambiguous term meaning different things to different people.

It has been defined internally from the viewpoint of software developers and externally from the viewpoint of end users of the software. But either way, early in the history of this industry, it was obvious that software development could not be done in an ad hoc manner but had to be subjected to methodologies to deliver products or services with attributes like robustness, reusability, and maintainability.

Over the last couple of years numerous methodologies have been introduced to achieve these quality goals. Some methodologies involve a disciplined and detailed process with strong emphasis on planning. Capability Maturity Model and Team Software Process are a few examples to name. Recently certain agile methods like Extreme programming and SCRUM were advocated as a new paradigm for high-speed, quick-to-market development. But one thing is sure—no matter which methodology is applied, the bottom line is that there is an impact of processes on the software quality factors.

This article describes why software projects still fail in this day and age, the business need for quality to reflect on a company’s bottom line, what tools Six Sigma for software offers, and how it compares to other methodologies.

Do software projects fail? Why?
Like any other project, software initiatives have three critical business drivers—cost, cycle time, and better quality. A failure in one realm is considered a project failure. One wonders what the state of IT projects is in terms of success/failure rate. The Standish Group report published in 1995, revealed a dismal picture:

1. 31 percent software projects were cancelled before completion
2. 52 percent projects cost almost double the original budget estimates
3. Over 50 percent of the costs associated with software were incurred after delivery

After 10 years even though the numbers improved in the latest reports, the top reasons for project failures are still the same—lack of user input, incomplete/changing requirements, and lack of executive support.

Quality has to reflect on the bottom line
When you look at an industry structure, it is apparent that the focus of the players depends on the relative competitive positioning. In a monopoly or oligopoly, the companies look at their cost and add a mark-up to get to a certain selling price. The equation looks like:-
Cost + Profit = Selling Price
But as the industry structure moves towards pure competition, the perspective of the equation changes. Mathematically, it remains same:-
Selling Price - Cost = Profit

Since players have similarly priced products, the only way to gain competitive advantage is to focus on minimizing the costs to add to the bottom line. High rate of failure, rework and cost of poor quality consume a large share of the IT projects. This has a direct impact on the bottom line making it even more relevant with the recent emphasis of Total Cost of Ownership that involves a holistic assessment of all costs incurred.

Cost savings can be realized only with methodologies that yield high quality initially and manage the change control process well. Six Sigma offers a set of tools to summarize the cost and benefit factors that contribute to estimating ROI. Six Sigma’s almost obsessive preoccupation with financial results ensures that executive buy-in remains till the project rollout phase. It also ensures business discipline in project selection, with a focus on maximizing the bottom line.

So what is Six Sigma for Software?
Six Sigma started from the Operations Excellence which values discipline in manufacturing with emphasis on efficient transactions, management of people, dedication to measurement systems, etc. But it became obvious that business success was more than the absence of negatives such as defects, delays or cost overruns. It then began to encompass positives like customer loyalty and delighters. From Operational Excellence, Six Sigma moved towards Customer Intimacy and Product Leadership value disciplines.

Six Sigma, in general, measures deviations from an ideal. The measurable thing may be the process used to make a toothbrush, whose material specifications and costs are compared to some ideal numbers. When applied to IT, Six Sigma measures attributes like network speed, reliability, load balancing, etc. But software development is not like manufacturing. Process variation can never be eliminated because:
l. No two modules are alike (performance includes an intrinsic degree of variability).
2. Greater variation in human cognitive processes (differences in skills levels).
3. Quality Assurance processes work differently for manufactured goods. Software products need testing only once before being accepted.

Yet the software development processes can be fully characterized by three basic measurements—time, size, and defects. And Six Sigma for Software (SSS) provides a holistic quality objective in product development, combining a programmers desire for bug free software and a user’s desire for an easy-to-use application. Although a few elements of the SSS toolkit are invoked within other methodologies like PSP/TSP (e.g. regression analysis for estimating models), there are many other tools available for generating quality software products.

There are charting/calculation techniques that can be used to scrutinize cost, schedule, and quality data. For technical development, there are quantitative methods for risk analysis and concept/design selection. Apart from the traditional Six Sigma Define, Measure, Analyze, Improve, Control (DMAIC) approach, the Design For Six Sigma (DFSS) approach offers feature, function, and cost trade-off decision tools for design of software products. Tools such as KJ analysis, Conjoint Analysis and Design of Experiments have high leverage in the world of new product development. In the software world, SSS can also heavily leverage re-use libraries that
consist of robustly designed software.

Six Sigma and other methodologies
Project characteristics that determine the relevance of a particular methodology can be based on following dimensions—project size, application domain, and criticality. The following matrix suggests a way of selecting a model for a certain projects:-
SSS differs from CMM/CMMI in that:-
1. It speaks the language of business, addressing costs, profitability and ROI.
2. In Six Sigma, projects are drawn from a portfolio that is identified through business strategy, while CMM linkage to strategy is weak. Six Sigma is typically applied to selected projects, while CMM is intended for all projects.
3. Six Sigma teams consist of employees from many departments of the company, not just QA (boundary-less collaboration).

Yet historically, it has been found that Six Sigma for Software begins to be cost-effective once the organization reaches CMM levels of 4/5. At that point, Six Sigma and approaches such as CMM/(I), PSP/TSP become complementary.

As IT becomes more involved as a value driver across different businesses, there will be necessity to use Six Sigma concepts to see improvements in business processes.

Ashu Bhatia, a Six Sigma Black Belt, is currently a Solutions Architect at CIBER (NYSE: CBR). He can be reached at abhatia@CIBER.com