TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: TW and QA From:written_by -at- juno -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Mon, 18 Oct 2004 18:30:13 -0600
> Are there actual assembly manuals that are more detailed
> than just reams of drawings and parts lists? It would seem
> to be the job of the engineer who specifies the parts to
> indicate placement and orientation. It would also seem to
> be the job of those engineers and CAD people to indicate
> units on the specs and assembly drawings.
> Maybe somebody who has worked on such a project can describe
> the process and where the TW fits in.
I do not involve myself with the space program, but in the case of Palm
Pilots, I can tell you that this was a large, ongoing beast of a project,
that never let up. It sucked my will to go on every day. More money was
involved than $264 million. Eventually, that is.
At least it gave me a daily opportunity to manage a huge project with
little or no thanks. What's not to love? Actually, I did love it.
My job was to translate engineer speak into average unskilled worker
speak. I was usually given Palm's specs, a full bill of materials (BOM),
schematics, plastics specs, LCD specs, PCB specs, and some basic manual
testing specs. Sometimes I had to dig for them, because cooperation could
be a serious problem.
I started demanding this material after our ill fated attempt to build
the modem for the Apple Newton. Remember that product? If any of you got
a bad one, sorry about that. I tried my best. Really, I did!
I was also given manufacturer's specs and samples of every electrical and
plastic component that went into the product. Things like integrated
circuits, crystals, coils, resistors, diodes, etc.; RF "black boxes,"
plastic cases, drawings of each PCB layer and the interconnects, samples
of all software and related enclosures, the cradle, and all data
regarding compatible accessories like the palm modem.
I was also given data from RMA, final test, ICT, hardware assembly, QC,
and environmental testing, in order to help determine what specific
failures or other problems were being reported. Perhaps a simple change
in procedures will stem the tide. For example, a 70% antenna failure rate
tells me that we need to look at the antenna. Actually, a 0% failure rate
scares me far more. Still, the feedback was quite valuable.
I also had the assembly documents prepared by the overseas manufacturer
we used in the beginning. Incidentally, we could eventually build Palm
Pilots for less money here in Utah, than any other place. So much for the
"US workers are lazy" or "the cost to make it here is too high"
I had to take the assembly drawings and create a step by step procedure
for every aspect of the manufacturing process. From SMT to ICT testing,
router to hardware, the Palm V heat clamp machine, final assembly and
testing; both manual, and pneumatic. Then on to packaging, RMA, rework,
and shipping procedures.
I had to create documents for QC that covered issues like the cosmetic
criteria. They had to know what a specific unit could be failed for or
not. Finally, I had to create documents for the Test Engineering and the
Manufacturing Services department.
Every document was intimately tied to every other document, and the Palm
documents tied to almost every other manufacturing or equipment document
in the system. One little change required reviewing a large number of
other procedures. Nothing was linked, so finding all related documents
took some effort.
After I wrote a procedure, I would take it to the production floor and
follow it step-by-step. This allowed me to determine if something is
missing or not really needed. I have built my share of Palm Pilots by
hand, PCB on up to final testing and packaging.
No wonder I developed a taste for gin. (smiley)
There were a number of basic document types I had to worry about:
Individual illustrated procedures for each workstation and a controlled
master procedure for document control. If one changed, so did the other.
Very hard to control, because anyone could edit a procedure and I might
never be told about the changes.
My goal was to make it easier for the assembly technicians to build, test
and package the product. I used scans of parts and other imaging
techniques to create step-by-step illustrated procedures. A simple
picture and a line of text often replaced a page full of engineering copy
that is quite often impossible for unskilled workers to understand.
If a specific thickness is required (the gap between cases, for example)
rather than give the physical spec to be checked, I instituted the use of
graded shims. Faster and easier. Rather than say something like "Verify
that 3M #123ABC adhesive is in place before clamping..." I would simply
refer to it by color. If it is not green, it is missing.
Eventually, I created more than 30 printed books. The problem was that
when a controlled procedure changed, it was not reflected in the printed
book. I had to review every change, because in some cases, a mistake like
a missing period might be a change some helpful wonk thinks is vital, so
the document gets a new revision number.
I wrote, photographed, researched, compiled or edited procedures for more
than 300 different versions of our modems, all OEM versions of the Palm
Pilot, the RIO MP3 player, NIC cards, and the 200 or so combo cards we
built over the years, for 200+ different manufacturers.
Not to mention, operator guides and procedures for the 30 assorted pieces
of equipment I personally trained people to use. Like the Grohmann
Automated PCMCIA Assembly Machine. All that one manufactured was rework.
So, that was my job and how I worked. I took the complicated and make it
easier to follow. I started with all available information, and proceed
from there. If I wrote or reviewed it, I actually tested it. That also
"Outside of a dog, a book is a man's best friend.
Inside of a dog, it's too dark to read." --Groucho Marx
Speed up your surfing with Juno SpeedBand.
Now includes pop-up blocker!
Only $14.95/ month - visit http://www.juno.com/surf to sign up today!
WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.