This article reviews some perspective on offshore outsourcing of software development work and provides some thoughts around how a Design for Six Sigma (DFSS) approach may help software organizations make better decisions about how, when and how much to deploy offshore.
Two recent conferences on software focused on the topics of Six Sigma for the software industry and general conference for the software vertical market. There was, as one would imagine, a tremendous amount of discussion relating to the offshore outsourcing of software development work to achieve significant cost reductions. This has been an emerging trend for about 10 years, but one that has been recently accelerated and subject to wild variations in success and efficiency. This article reviews some perspective on this trend and provides some thoughts around how a Design for Six Sigma (DFSS) approach may help software organizations make better decisions about how, when and how much to deploy offshore.
A Historical Perspective on Offshore Outsourcing
For the purpose of learning where others have been successful and where they have failed to meet expectations, it is often useful to look at history when pursuing the discussion of a new trend. While offshore development is a relatively new trend in software, the concept of outsourcing manufacturing and service operations has been going on for more than 50 years. Asian countries, initially Japan, later Korea, and then “The Asian Tigers” (Malaysia, Singapore, Thailand, Taiwan, Hong Kong and The Philippines) took a prominent roll in developing government-led, socio-economic policies to drive economic success through the pursuit of initially “low tech” manufacturing work, utilizing their low cost and available labor force. While in many ways, this created a better balance and improved economic parity between East and West, these actions also stripped away many good paying jobs from the western economy. This led to extensive layoffs and the downturn of industries, which never recovered. These industries included steel, clothing, certain automotive and appliance segments, electronic components, battery cells, and the list goes on. In the global scheme of things, the West did the right thing in helping to develop the once struggling Asian economy. But to their credit, this core of Asian companies migrated from their government-sponsored status and embraced the market-driven system that we pulled them into.
They began to understand how to differentiate their products and services, and in the last 50 years have become dominant players in the world market. From a global perspective, these countries are a great success. The western economies, while feeling the pain of the aforementioned job loss, found a new niche in the innovation and manufacture of “higher technology” (communications, Internet, bio-technology, aerospace and software) products. These industries also created a massive service-based economy, which virtually replaced the jobs lost in the first wave of offshore manufacturing and carried the western economy through the bustling 1990s. History’s lessons are valuable since they teach us that, through these activities, we can create a better balanced global economy, contribute to political stability while reducing our cost base and improving profitability. But it is not without a cost or consequence of some kind. We need to be aware of the short- and long-term consequences of these decisions and plan accordingly to ensure our place in the global scheme of things. We also must make good long-term strategic decisions and carefully evaluate the immediate and future costs and risks in pursuing an offshore strategy.
Software Outsourcing – A Lifecycle Cost Decision
Because the west is now heavily reliant on its service-based economy (and the plethora of software that supports it), the recent acceleration of the trend to offshore outsourcing of software and service jobs needs to be carefully considered. Again, countries with an ample supply of highly educated but relatively low cost labor are eager recipients of our outsourcing efforts. These countries have active government-sponsored socio-economic initiatives and incentives to win our business and grow their segment. Countries actively pursuing this work include India, China, Russia, Ireland, Israel and others. Again, as history dictates, helping to grow these economies will have strong global benefits and help us to become more profitable. However, it is 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. How, what, why and even “if” should be considered and quantify if we desire to be successful in these efforts and realize the advertised benefits. We must then make outsourcing a Lifecycle Cost Decision or we could suffer a significant disappointment or perhaps even higher cost in the long run.
A recent CIO Magazine 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 tradeoff $100-an-hour development work for $20 an hour, it hardly seems worth the trouble. In fact, in many cases, if we could simply find a way to reduce current costs (through efficiency, quality and cycle time improvements), we might not need to go offshore at all. However, there are cases when offshore outsourcing does make sense. But only when the customers needs, the businesses needs, and the offshore suppliers capabilities are aligned by a clear understanding and are defined in a quantifiable manner. Simply stated, if we outsource a poorly specified, unstructured, complex project, we 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 often 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 actionable detail. 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 CMM Level 3 or 4 company, it does not mean that the project outcome will exhibit Level 3 or 4 performance characteristics. This is especially true if the base companies’ 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 had 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 the cycle time to complete the requirements phase of a typical software project. DFSS also can help keep projects on schedule and under control through the Tollgate Review features of DFSS 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. (We will discuss DMADV, an acronym for Define, Measure, Analyze, Design/Build and Verify/Control. There are others but most display similarities to DMADV.) As teams accumulate cycles of learning with this roadmap, it becomes a highly efficient way to quantitatively establish a 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 very few who completely understand or who have demonstrable results in the application of Six Sigma to software development. Many have simply relabeled their CMM efforts as Six Sigma and pass that off as a competitive advantage. The point here is to do your homework: Do not 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 KJ’s, Context Data Mining, Process Models, Kano Planning, Use Cases, Analytical Hierarchy Process (AHP) and CTQ’s. 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 is quickly assimilated as “part of the process” by the participants.
In the Analyze phase, alternatives and tradeoffs are understood. Using industry accepted estimating models, concept selection scorecards, various 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) is also explored as an expression of VOC to VOB balance, examining factors including duration, effort, defects, cost and risks. Raleigh Curves help to predict staffing requirements and defect discovery distributions.
During the Design/Build phase of DMADV, a translation of the Voice of the Customer 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 Mode Effect Analysis (FMEA) into actionable and measurable tasks. 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/Control phase sets up the project for an ongoing, regular, and quantitative review and verification process. Again, because we now have a metric-driven project culture in place, we 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 our processes and eliminating as much of that variation as possible at root cause. In successful organizations, this is the key to achieving breakthrough results. Too often when we look at cost as our only metric to make decisions, we are falling into a trap. Cost is a lagging and dependent variable. By hyperfocusing on it, we inherently miss the characteristics driving it. In all cases, what changes cost is a collection of many independent variables (leading indicators) which are not trapped 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. On the topic of offshore outsourcing, too many organizations have been falling into the trap of focusing on cost and failing in their primary objective of saving money. Don’t become one of those statistics.
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. Six Sigma, specifically DFSS, provides a structure, a rapid deployment option and, from the early adopters results, an emerging success story to better manage the way we plan for, deploy and succeed in our offshore outsourcing endeavors.
About the Author
Bruce Hayes is co-founder of Six Sigma Advantage, Inc. where he focuses on Business Development, Executive Coaching and Training and curriculum development in Six Sigma for technology. He is an operations professional and consultant with more than 27 years of experience. As a senior executive at Motorola, he was one of the key contributors to developing and “operationalizing” Six Sigma. Mr. Hayes also was co-founder and president of a leading conventional Six Sigma consulting firm; and he has served as an executive coach and mentor for many fortune 500 companies which have successfully implemented Six Sigma. He is now engaged in porting his experiences into the technology and software arenas. Mr. Hayes can be reached via email at firstname.lastname@example.org.