Practical outsourcing advice and case studies for IT and business process outsourcing.
  Home > Outsourcing Tactics  > Quality Methods / CMM / ITIL / Six Sigma Search:
 
 for    
 Highlights: Buy Books|Outsourcing Blog | Quality Events and Training Calendar | Quality Dictionary | Outsourcing Discussion Forum | Outsourcing Jobs | Outsourcing News and Press Releases | Free Outsourcing Newsletter | Online Surveys
 Free Newsletter!  
Improve your
Outsourcing skills and knowledge


Sign up today!
  Manage Subscriptions
  What is Outsourcing?
  What is Offshoring?
  What is BPO?
  Offshoring to India
  Offshoring to China
  Glossary of Terms
 Sourcing Directory 
  Outsource by Function
  Outsource by Region
  Outsource by Industry
  Outsourcing Strategy
  Outsourcing Tactics
  Legal
  Research & Statistics
  Tools & Templates
  Vendors & Consultants
 Channels 
  Business Process Mgt
  Innovation
  Six Sigma
 Quick Access 
  Help
  Search
  Advertise Here
  Article Archives
  Newsletter Archives
  RSS/XML Feeds
 User Feedback 
  Please suggest site
  improvements.
 
  [ larger form ]

Using DFSS To Improve Offshore Outsourcing Efficiency

Bookmark This Page Bookmark This Page
Email This Page Email This Page
Format for Printing Format for Printing
Submit an Article Submit an Article
Outsourcing Article Archive Read More Articles

By Bruce J. Hayes

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.

Some Background

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. Raleigh curves help to predict staffing requirements and defect discovery distributions.

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.

Useful Links:

Six Sigma Advantage
http://www.6siga.com/

More about Design for Six Sigma
http://www.isixsigma.com

 

About the Author:

Bruce J. Hayes is a co-founder and managing partner of Six Sigma Advantage. He was instrumental in the development of the company's Six Sigma for Software and Technology services. He was formerly a senior executive at Motorola where he also was a lead assessor for Motorola's award-winning Quality System Review (QSR) process. He also is a certified Malcolm Baldrige National Quality Award examiner. Mr. Hayes has lead dozens of pre-deployment and organizational assessment teams. He has served as an executive coach and mentor for many fortune 500 companies which have successfully implemented Six Sigma. Contact Bruce J. Hayes at bhayes (at) SixSigma-Advantage.com or visit http://www.6siga.com/.

 
Rate This Article: 
  Poor    Excellent     
          1    2    3     4    5
Copyright � 2003-2014 – Sourcingmag.com, CTQ Media. All Rights Reserved
Reproduction Without Permission Is Strictly Prohibited – Request Permission


Publish an Article: Do you have a sourcing tip, learning or case study?
Share it with the largest community of Outsourcing professionals, and be recognized by your peers.
It's a great way to promote your expertise and/or build your resume. Read more about submitting an article.

Outsourcing AdLinks
AdLinks Information
 
Home | Discussion Forum | Event Calendar | Job Shop
Link To Sourcingmag.com | Report A Problem | Submit Article For Publishing
 Terms of Service. ©2003-2014 Sourcingmag.com, CTQ Media. All rights reserved. v1.0, 0.1
About Sourcingmag.com | Contact Us | Privacy Policy | Site Map