Outsourcing Knowledge Work - Why Not?
(download zipped Word 6.0 version)

Rick Dove, Paradigm Shift International, www.parshift.com,

All industrial sectors are experiencing an acute shortage of knowledge workers, and the projections call for a worsening situation. Yet the alternative of outsourcing much of this work is met with adamant objections. Here we will examine why outsourcing is not done, attempting to get a clearer picture of the problem. With a better understanding we might be able to solve it.
   In June of 1999 Automotive Manufacturing & Production began running a three-part series entitled "Labor: A Study of the Automotive Industry's Scarce Resource." For OEMs and suppliers alike, three "labor" categories were beyond the "moderate scarcity" point: Product engineers, programmers, and computer support technicians; classic knowledge worker categories.
   When it comes to outsourcing knowledge work, especially the kinds that generate intellectual property or reside in the area of corporate core competency, it is clear that discussion violates both taboos for polite company engagement: religion and politics. Nevertheless...
   A while back we were invited to conduct a discovery workshop at Rockwell Collins Avionics, with the focus on Integrated Product Teams (IPT). The idea was to analyze ongoing IPT activities that crossed the boundaries of marketing, engineering and production, and identify the dynamic issues that these teams faced. Then, in a subsequent exercise, create a fresh design for a general teaming practice using agile reusable-reconfigurable-scalable design principles to improve the overall responsiveness to product life cycle dynamics.

Trust is the core problem: An outsource isn't family,
and can't be expected to act with the same loyalty.

The workshop group included more people from outside the company than insiders, so the analysis enjoyed some piercing questions and objectivity free of any internal political or cultural constraints.
   Production team members had felt that engineering team members were being uncooperative when they did not attend to design issues, which arose after the handoff to production, with an equally perceived sense of urgency. The unanticipated result was that the real issues had their roots in a lack of resources rather than in a breakdown in the teamwork practice.
   Preliminary analysis pointed at an inadequate team-practice design: the operational framework for these teams was in conflict with other engineering objectives. The underlying conflict stemmed from the scarcity of engineering resources – after the handoff, key engineers were immediately applied to the next engineering project, and quickly dedicated to the next set of immovable and tough deadlines. When attention needed to be revisited on a prior design project, these rededicated resources could not be immediately reassigned without seriously jeopardizing the new project.
   At face value it appeared that the company simply and constantly bit off more than it could chew. A closer look showed that both the nature of their projects and their resource environment were changing rapidly away from their traditional model: New government projects were smaller and more frequent, and the engineers required for the increasing design load were harder to hire and harder to retain. Engineers are highly mobile and in short supply everywhere – they have attractive alternatives from which to choose.
   The company had growth in mind, but was hard-pressed to obtain the necessary knowledge workers just to maintain current levels of revenue. The solution would not be found in better teaming practice – but we didn't know this until we analyzed the problem in some depth (here, July '99, or www.parshift.com/Essays/essay055.htm).
   A subsequent discovery workshop at Pratt and Whitney's Liquid Space Propulsion group peeled this onion further. In their case we focused on engineering analysis work – something that new rocket engines and fuel pumps for space applications need a lot of.
   This is high pressure, temper testing work: equipment test failures need immediate explanation and immediate alternatives, the cost of a blown engine or pump test is very high, the government customer is looking over everyone's shoulder, a new engineering analysis is needed overnight, an analysis is needed before the design is done, and new analysis technology and software seems to come out faster then the time it takes to learn it. Not a job that attracts career-long specialists. Generally a job staffed by engineers rotating through experience-developing positions. When kept too long in the analysis section, turnover increases and a short supply becomes shorter. Pratt wanted ideas on how to reengineer their approach to analysis work. They needed more of it done, and all of it done faster.
   Many members of the workshop group had also been through the exercises at Collins, and were quicker this time to identify the crux of the matter as a resource shortage, rather than as a problem in analysis methodology.
   Questions by the outsiders, who didn't know any better, as to why this activity wasn't subcontracted or outsourced met with a quick and knowledgeable answer: "We've tried it and it doesn't work."
   Indeed they had, as additional questioning uncovered additional experienced answers: "This kind of analysis is so tricky and so unique that if you're not in our business you don't have the necessary experience to be good at it. There are not enough 'qualified' resources anywhere, so it is unlikely that we'll find them in a non-competitive outsource company. The engineering process is iterative and requires a daily face-to-face working relationship between the engineers and the analysis people. Transferring files and data between in-house and outside resources has compatibility problems, especially if a contractor uses different analysis packages than we do."

   Some in the workshop thought that there were ways to address each of these objections; ways that had been employed successfully in other environments.
   But then came the coup de grāce on the outsourcing possibility. Two of the participants in that workshop were from Boeing Rocketdyne, a direct competitor to Pratt. They were even more adamant about why this kind of work can't be outsourced: "Designing motors and pumps for space application is different. Engineering analysis is in the critical path of new product development; it is a major factor in cost and time to market; and it ultimately determines the features of the product. Engineering analysis is a strategic skill and core competency that must remain proprietary."
   With the force of these knowledgeable and experienced answers the workshop looked elsewhere for improving the productivity of analysis work. In vain. Outsourcing was the only alternative on the table. But since those with the problem were so adamant about its inability to address the problem successfully, we focused our remaining effort on reaching a consensus as to why that was – by defining the problem as perceived by those who faced it.
   The result was a list of issues that were real barriers to the specific problem of outsourcing engineering analysis work for rocket design. But others in the workshop, from completely different industrial sectors, agreed that these were the same barriers they faced. The catalogued issues were the result of a response ability (Ra) analysis, which asks structured questions about problem dynamics.
   Questions asked in the proactive categories included: What stands in the way of creating a working relationship with an outsource? How do outsource resources impede the creation of a finished project. What types of ongoing improvement activity during the course of a project is impeded with outside resources? What issues of technology migration arise that might lead to incompatibilities between inside and outside engineering tools? How about difficulties related to the addition of new skills to a working group?
   Questions asked in the reactive categories included: What types of corrective action are unique to outsource relationships? What kind of breakdowns occur that would need correction? What types of variation are there in outsource relationships that create problematic issues? Where does outsourcing cause expansion and contraction problems? Does reconfiguration of the relationship or resources become an issue with outsourced knowledge work?
   The purpose of this structured questioning was to define the problem of outsourcing knowledge work both comprehensively and in terms of its dynamics. Perhaps this definition shows us an unsolvable problem in certain instances, but in others it may guide the design of a solution.
   As it turned out, the discovery workshop immediately following the one which generated this problem definition was going to look at the same thing from the other end. The host of the next workshop was interested in agile relationships that would make it an attractive R&D outsource arm for any company. More on this to come.

©1999 RKDove - Attributed Copies Permitted
Essay #057 - Published 9/99 at ww.parshift.com
Published 10/99 in Automotive Manufacturing & Production, Gardner Publications

Would you like to offer some thoughts or add to the dialog? Your sending of a comment automatically grants us permission to edit and post at our discretion. Send your comment to
========= Reply =========================
From: "Casper, Bert" Bert.Casper@Remmele.com, Date: Mon, 13 Sep 1999
Rick, I don't know if you have also seen the article on retirement of knowledge people in the 7/12/99 WSJ under "The Outlook" column on P.1, or the article in Aviation Week & Space Technology 6/21/99 issue titled "People Issues Are Cracks In Aero Industry Foundation" on P. 63, plus the many letters to the editor in subsequent issues. But if you access these issues, you will note that your thoughts on the issue in your essay concur with the findings there. We are considering how to deal with, and take some advantage of, this situation, but the issues you mention in your box are valid and daunting. ("Why you won't outsource..."). Tough situation!
Bert Casper, Remmele Engineering, Inc.

========= Reply =========================
From: karthikeyan_s@nipunaservices.com , Date: Tue, 24 Aug 2004
I want to tell potential customers which processes to be outsourced or co sourced when & why? And to mention the detail in a rating scale, by showing how much cost I can save and increase the productivity and decrease the manpower. Especially looking for mechanical engineering work.

========= Reply =========================
From: (Rick Dove), Date:  24 Aug 2004
Then you must know your customer's costs, process problems, and strategic values - and then build a value proposition. Generally this must be done on a case by case basis from a template for analyzing the opportunities. I suggest you study the work done by Ronald Coase in 1937:


And I suggest you read my book that will be available in November/December 2004..."Value Propositioning - Book One - Perception and Misperception in Decision Making":


========= Reply =========================

Home | Library
Send mail to with questions or comments about this web site.
© 1994-2005 Paradigm Shift International - Attributed Copies Permitted
Last modified: April 25, 2005