Offshore outsourcing of software development work has been subject to wild variations in success and efficiency. A Design for Six Sigma (DFSS) approach is one way that your software organization can make better decisions about how, when and how much to deploy offshore.
It’s easy to get caught up in the offshore groundswell and make a quick, uninformed decision about outsourcing activities in order to show a rapid cost reduction. Yet, to be successful in these efforts and realize the advertised benefits, you need to consider the motivations for your offshoring and quantify the dimensions of the work as much as possible. Software companies must make outsourcing a lifecycle cost decision or they could suffer a significant disappointment or perhaps even higher cost in the long run.
A 2003 CIO article, “The Hidden Costs of Offshore Outsourcing,” noted that as much as 72 percent of stated cost savings of typical offshore projects was lost to the costs of start-up, transition, productivity and maintenance. When considering that a primary objective to going offshore is to trade $100-an-hour development work for $20-an-hour work, it hardly seems worth the trouble. In fact, in many cases, if a company could simply find a way to reduce current costs (through efficiency, quality and cycle time improvements), it might not need to go offshore at all. However, there are cases when offshore outsourcing does make sense — but only when the customer needs, business needs and offshore suppliers’ capabilities are aligned by a clear understanding and are defined in a quantifiable manner. Simply stated, if a company outsources a poorly specified, unstructured, complex project, it can expect in return a cheap but dysfunctional piece of software requiring many person hours of post-release support and perhaps even cancellation.
Most software professionals understand that defects are introduced into the software process at the various stages of development, namely requirements, design, coding, testing and release. Industry data shows that most defects are inserted early and found late, at the most expensive stage to fix. One of the most common modes of failure in a software project is poor requirements definition and planning — including getting requirements into proper context and detail that can be acted on. In most offshore outsourcing scenarios, the requirements phase of a software project is still in the control of, and maintained by, the organization seeking to outsource the development and coding.
Just because an offshore company professes to be a CMMI Level 3 or 4 company, it doesn’t mean that the project outcome will exhibit Level 3 or 4 performance characteristics. This is especially true if the base company’s requirements process exhibits less than Level 1 characteristics. Due to communication, language and cultural limitations, the offshore supplier might never administer the requirements phase to everyone’s satisfaction, even if they have the fundamental skills.
How Does DFSS Help?
The tools of software DFSS can greatly reduce the risk of offshore outsourcing failure by rapidly deploying a roadmap, simple tools and behaviors designed to dramatically reduce the rate of requirements failures and cycle time to complete the requirements phase of a typical software project. DFSS also can help keep projects on schedule and under control through tollgate reviews based on quantitative dashboards. Through one of several accepted DFSS roadmaps, an organization can quickly deploy a measurement-based process to remove the subjectivity of requirements data and dramatically improve the quality of subsequent coding activity. DMADV (Define, Measure, Analyze, Design/Build and Verify) is the roadmap used here, but there are others that are similar. As teams accumulate cycles of learning with this roadmap, it becomes a highly efficient way to establish a quantitative baseline for development activities and to continually improve these activities.
As a word of caution, there are offshore companies soliciting business on the premise that they embrace Six Sigma or have significant competency in Six Sigma. In fact, there are few that completely understand or that have demonstrable results in the application of Six Sigma to software development. Many have simply relabeled their CMMI efforts as Six Sigma and pass that off as a competitive advantage. The point here is that you must do your homework: Don’t expect to get a Six Sigma software product from an organization claiming to be Six Sigma-certified without putting something in — especially on the requirements end of the lifecycle and in the management of the effort.
The DFSS Process — DMADV
In the Define and Measure phase, development teams are required to use tools such as KJs, context data mining, process models, Kano planning, use cases, analytical hierarchy process (AHP) and critical-to-quality elements (CTQs). These tools must be administered in a specific sequence (in some cases in an iterative manner) to realize the full benefit. Initially, it may take some additional time on the first few projects, but the investment will be repaid in subsequent efforts.
In the Analyze phase, alternatives and tradeoffs are understood. Using industry-accepted estimating models, concept selection scorecards, various voice of the business (VOB) metrics and risk measures, the development team develops a full and quantitative profile of the alternatives and tradeoffs available to them. Capability (from a statistical perspective) also is explored as an expression of voice of the customer (VOC) to VOB balance, examining factors including duration, effort, defects, cost and risks.
During the Design phase of DMADV, a translation of the VOC into quantified and prioritized development terms occurs. The main purpose is to convert what was learned in previous phases, through tools such as quality function deployment (QFD) and failure modes and effects analysis (FMEA) into measurable tasks you can act on. Once this occurs, data-rich reviews looking at items including total containment effectiveness (TCE), phase containment effectiveness (PCE) and defect containment effectiveness (DCE) provide solid business insight (converted into dollar impact) for ongoing monitoring of project decisions and consequences. Because of the quantitative nature of these measurements, risk can more effectively be managed.
The Verification phase sets up the project for an ongoing, regular, and quantitative review and verification process. Again, because DFSS practitioners now have a metric-driven project culture in place, they have critical metrics, baselines and goals around those items that are critical to project success as defined by both the customer and the business. It also is the opportunity to be sure that processes are under “procedural control” (required actions and metrics are actually fulfilled). Visual dashboards are usually implemented to make out of control situations visually obvious to reviewers for quick and concise action.
Cost Is Not the Driving Metric
The essence of Six Sigma is about measuring and understanding variation in processes and eliminating as much of that variation as possible at the root causes of variations. In successful organizations, this is the key to achieving breakthrough results. Too often when companies look at cost as the only metric to make decisions, they are falling into a trap. Cost is a lagging and dependent variable. By hyperfocusing on it, organizations inherently miss the characteristics driving it. In all cases, what changes cost is a collection of many independent variables (leading indicators) that are not captured by the typical accounting system in a useful way. The statistical analysis, prioritization, characterization and improvement of the right variables (or combination of variables) at the right time is what gets desired results. In the matter of offshore outsourcing, too many organizations have fallen into the cycle of focusing on cost and failing in their primary objective of saving money.
More and more successful organizations are using DFSS for software to either, 1) use as a tool to eliminate risk and manage the offshore outsourcing project, or, 2) save costs onshore when offshore deployment is prohibited by certain environmental factors (confidentiality, sensitive content, etc.) or simply not viewed as an option. Design for Six Sigma provides a structure, a rapid deployment option and, from the early adopters’ results, an emerging success story to better manage the way companies plan for, deploy and succeed in their offshore outsourcing endeavors.
Six Sigma Advantage
More about Design for Six Sigma