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
(Rick Dove), Date:
24 Aug 2004