RE: Boeing Tech Pubs going offshore? (long)

[Richard Lippincott <richard -dot- lippincott -at- ae -dot- ge -dot- com>]

Sorry this is a bit long. I'm consolidating some questions and answers, I
didn't see this when it first came up on Friday. I can offer some
non-hypothetical answers to questions asked here. Although I work for
Lockheed Martin, our office (about ten tech writers) is under contract to
write maintenance manuals for GE Aircraft Engines. 

The original article said:

"Boeing is using General Electric as a model for outsourcing of its
technical publishing. GE partners with Adexus, a publishing company based in
Santiago, Chile."
This is absolutely true. GE is transitioning a number of commercial engine
maintenance manuals to Adexus this year. It will cause the loss of a number
of tech writing jobs here in the US. 

One of those lost jobs will be mine, our office is closing in November as a
direct result of GE's arrangement with Adexus. So although I'm not directly
involved with the Boeing decision, I certainly have an understanding of what
has happened there. Based on the comments so far on the list, looks like
I've got the closest to first-hand experience with this issue. 

Rose Wilcox asked some interesting questions:

>What if the airlines don't agree to use the standard technical manuals?

It's likely that "agree" isn't really up for consideration here. The
airlines will be offered standard tech manuals, take it or leave it. "You
want our airplane? You'll take the manuals that we offer."

>What are the downsides of the standardization?  

The biggest downside that I can see is the communication gap between the
engineers and the writers. This is a geographical issue as much as a
language issue. 

A while back, I had a conflict with an engineer regarding a new repair
procedure. I read what he had written, it didn't make any sense. We had some
e-mail and phone go-rounds in an attempt to clarify it, no luck. The issue
was finally settled when we sat down in a room with a box full of parts, and
he physically showed us what it was he was trying to say. This was possible
because our office and the GE plant are a short distance apart, one can get
from here to there quickly and have the opportunity to play with the parts.
This isn't going to be possible when the writing is done in Chile.

And that's no knock on the writers at Adexus. The other side of the coin is
that recently I've been working on some procedures for thrust reversers
manufactured in Italy, for installation on an airplane built in Brazil. I
have no access to the hardware. I've written the procedures as best I can,
and they've passed all the reviews, but I'd feel a heck of a lot more
comfortable if I could stick my head in one and see how it operates. 

When dealing with complex procedures, there is a need for the writers to
have direct access to the product being documented. In the case of hardware
documentation, the writers need at least the ability to see the hardware on
occasion, just as in the case of software documentation, the writers need
the ability to run the system and see the code on occasion. The move of the
tech writing jobs from Seattle to Chile will remove this possibility. 

>What solutions are there to potential problems?

At this point, at least on our end, the management operating assumption is
that there will be no problems. The outsourcing of the manuals is being
promoted as a wonderful idea. The reality is that due to the bottom line
aspects, management is determined to -make- it work, even if the only way
that can be done is to ignore any problems that arise.

>What do you mean by standards? Standard format, content, language usage?

Part of that has an easy answer: the manuals will be written to the ATA 100
specification, using Simplified English. But the other part of the answer is
that the manuals will be written to a standard product, a "green airplane."
Currently, the aircraft manuals tend to reflect customer specific cockpit
configurations and hardware options. Standard manuals will reflect a generic
design.

Best example I can think of is an automobile owner's manual. You buy a new
car with some options, you pull out the owner's manual. The illustration of
the dashboard looks -mostly- like your car, but there are some differences
because it doesn't show the options you bought, and shows some you didn't
buy. It's close enough that you can find all the important controls, but
it's not an item-by-item match. That's what the aircraft manuals will be
like.

The aircraft manufacturers believe that this will not be a problem because
the airline's own training programs will teach the aircrews the specifics of
their own flight deck layouts. 

> How would the overseeing be done?

The GE manuals are written in SGML on a Documentum system that is networked
both to the GEAE plants and Adexus in Chile. The Adexus writers produce the
document, then submit drafts for review using Adexus. Engineers, product
support, and lawyers at GEAE review the document, mark up comments on a PDF
file that is accessible through Documentum, and then task the writer to make
corrections. There are only limited (if any) provisions to check the
procedure by actually performing them on the hardware prior to doc
publication. 

I would expect Boeing to adopt a similar system.

>Has anyone done any time estimates for how long re-doing the language usage
might cost if outsourced to someone who isn't fluent?  Is it really cheaper?

Time estimates, no. Cost-per-page estimates, yes. Unfortunately, Adexus came
in at just under a third of the price per page of what we were doing. GEAE's
opinion was "At that cost, we can have it redone three times and still be
saving money." 

There's another factor that has to be considered. Aerospace companies
routinely offer an option of Field Support contracts, and those contracts
are viewed as a source of income. Tech pubs is seen as a drain on income. 

Here's an example of how it works: Flybynight Airlines inks a Field Support
deal with Dodo Aircraft Company, the supplier of their new airplanes. Dodo
then provides a number of full-time Dodo employees to the Flybynight
Airlines sites. The Field Support technician's job is basically to sit in an
office near the flight line, and keep current on what Dodo is doing in terms
of engineering changes and maintenance problems. 

When the Flybynight mechanics have a job to do, they turn to the tech
manual. If they can't understand the procedure, they go to the Field Service
rep and say "How do we do this?" The Field Service rep says "Let me get that
data" and calls the engineers back at Dodo, and gets directly from them an
explanation of what to do. The Field Service Rep then walks the Flybynight
mechanics through the process, and when they've got it the Rep goes back to
his office and waits for the next problem.

The problem with the above for tech writers is that no one cares if the
procedures are accurate. In fact, because Dodo is making a nice chunk of
change off that Field Service contract, it's actually to Dodo's advantage to
produce tech manuals that the Flybynight mechanics can't understand. Dodo is
able to cut costs by letting go tech writers, and contracting out to the
cheapest possible source. Dodo gets tech manuals that meet the requirements
for certification, (the FAA requires documentation, but doesn't require
-good- documentation), but the manuals don't interfere with the profitable
field service contracts.

There is that downside that occasionally an airplane will suddenly
malfunction in mid flight and fall out of the air. But hey, why dwell on the
negative?

Len asked:
>Seems like a logical business decision to me.=20
>I mean, who says that techwriting source content has to be in English in
>the first place?

The FAA says so. If the manuals aren't written in English, then the aircraft
can't be certified for use in this country. If the aircraft is built in this
country, it has to be certified for use in this country. So, the tech
manuals have to be in English either way. 

Regarding the "cost to translate" the manuals. Based on what I've seen (and
I do have direct access to some of the documentation written by this firm),
it's not being translated. It's being written in English by people who speak
English as a second language. 

Goober asked:
>Would you rather the headline read "Boeing Division A
>Smoldering Wreck, Chivalry To Blame"?

How about the headline "Flybynight Airlines Flight 123 a Smoldering Wreck,
Poor Maintenance to Blame?" (See follow-up comments below.)

Mike O asked:
>Does anybody know what that Boeing tech pubs group does? Do they
>develop or test the content,

I can't answer for Boeing as I've never worked there, but based on my
experience at other aerospace firms, it's likely that this is exactly what
they do. 

> or do they just manage the publishing
>workflow (I suppose SGML, Interleaf, etc, which still is not trivial).

In other words, just pretty up what the engineers write? No. You wouldn't
want that to happen. You think software engineers don't know how to write?
Having worked with both types, trust me, software engineers are literary
geniuses when compared to aerospace engineers. 

>I suspect that the people who are actually developing the content are
>not going to be outsourced. 

Unfortunately, that's exactly who is being outsourced.

Writing an aircraft manual frequently happens like this: The tech writers
get an engineering notice that "Beginning with airplane production number X,
we're changing the design of the following system components..." The writers
then have to order up sets of blueprints that show the new part design and
installation. Using the blueprints, the writers have to figure out the
installation, removal, inspection, cleaning, and repair procedures. Got a
question? Call the design engineer, or better yet go out to the assembly
line and talk to the people who are putting the new parts into the new
airplanes. This isn't going to be easy for Adexus, being in a different
hemisphere from the Boeing and GE plants.

Mike Stockman said:
>Let's not raise up the spectre of crashing planes caused by outsourcing;
there's no link.

I used that spectre above, and reading Mike's comment I have to say
technically he's correct and it probably isn't fair to use a scare tactic.
On the other hand, part of the reason why there is "no link" is because, at
this time, there's been so little outsourcing of aerospace manuals that
there isn't any significant data. It's my opinion that there will be
problems, it may be Mike's opinion that there won't be. Right now, June
2003, there isn't enough data to know which one of us will turn out to be
correct.

But Mike seems to put a lot of faith in Boeing's QA of the manuals. The
problem is that Mike doesn't know what that QA process is or how good it is.
Neither do I, firsthand. But we can't assume that it's going to catch the
critical mistakes, even if we -want- to assume it will. In a way, this is
just a variation of the old "tech writer's don't need to understand the
content" argument. In this case "Don't worry if the Chilean writers don't
know anything about aircraft maintenance procedures. Boeing QA will fix the
mistakes." The problem in the process may be (as I've experienced in other
places) when the reviewers just glance over the draft, and don't stop to
think if what is written actually works. 

I've seen cases where engineers provide data that just doesn't work in real
life. Parrot back that data to the same engineer for review, and it will get
a passing grade and QA approval. Then the customer takes it out into the
field, and discovers it doesn't work. ("Call the field service rep...")

My fear (and I admit I don't know the facts) is that Boeing may be in a
situation similar to what GE is. Our office has a group of tech writers that
includes a core group with extensive experience in hands-on engine
maintenance. These are people who spent years building and repairing the
engines they now write about. Other Lockheed Martin divisions hire tech
writers from a pool of retiring aircraft mechanics and flight engineers.
I'll bet Boeing does the same. The result is that the writers deeply know
the subject matter, and are able to spot issues such as "If you want the
change -here- then it's going to also affect systems covered -there-..." and
"We can incorporate this as you say, but don't forget that this won't
actually work on the systems you built back ten years ago which had the
following differences..." 

After several years of this, the GEAE "system" tends to rely on the
expertise here, and there is an assumption that "The writers will catch the
problems, so we don't have to pay very close attention to it. Whatever they
produce is good." GEAE hasn't yet demonstrated the radical paradigm shift in
thinking necessary to go to "The writers don't have any experience with the
systems, we need to take a good close look." Boeing may be different. Or
they may be the same. My fear is that they're the same.

And if that sounds like a knock specifically aimed at the Adexus writers,
it's not intended as such. The problem is that Boeing is taking the work
from the people who intimately know the product and giving the work to
people who have no experience with it. Boeing will have much the same
problem if they decide to award the pubs contract to me personally and my
co-workers in this office. Airplanes are amazingly complex systems to
document, and from my experience and observation a new tech writer with no
experience with the specific product requires four to five -years- to come
up to full speed and reach the point where you can count on the writer to
get it right with a minimum of review. I have a bad feeling that Boeing has
forgotten this, and is working under the assumption that tech writers are a
commodity. "Our group is getting it right, therefore the outsourced group
will immediately be able to get it right also." 

There's another sordid part of the story that has to be considered.
Aerospace companies in this country theoretically have one last backstop,
but it's more legal than practical. As mentioned above, the docs have to get
FAA approval. That gives the aerospace companies an out, if there is a
problem later. "Our procedures were wrong? But we submitted them to the FAA
for review, and the FAA signed off. See? We have a signature here. The
failure is the FAA's fault for not catching the mistake." The problem is
that the FAA reviews aren't looking for technical accuracy, they can't
because they're overwhelmed with material to approve. The FAA reviewer is
mainly looking to see if the docs meet the ATA 100 layout spec, and match
style and format. 

So, with FAA signoff to provide some legal protection, and profitable field
service reps on location to assist the customer in how the work is
-actually- done, why should the aerospace companies really worry about the
content and quality of the docs? Tech pubs is just a financial drain, after
all.

Me? I'm taking the train next time. 


--Rick Lippincott
  Lockheed Martin
  Saugus, MA






^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Robohelp X3, from eHelp, lets you quickly and easily create 
professional Help systems for all your Windows and Web-based 
applications, including Net.

Buy RoboHelp Office X4 by June 13th and receive
$100 mail-in rebate, Plus FREE RoboHelp Plus Pack.

Order RoboHelp today: http://www.ehelp.com/techwr-l

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.