Technical Writing - Help Training Supervisors in the Basics

J

JRKH

One of my tasks is Document control and I am trying to work with our Supervisors and managers to get things properly documented and up to date.
Currently, we tend to ask the supervisor to write things out and then we try to turn this into a controlled document.
Of course this process has a lot of snags (and frustration) when we have to go back and ask questions, get clarifications etc.

I've started writing down some brief "tips" that might be useful for the management people to know and was thinking about making this into a PPT that we could run our management folks through.

Of course I don't expect them to become technical writers. (Hey I need my job.:D) I just think that it would be useful for them to know what kinds of things we look for in a procedure, instruction etc.

Some points that I have touched on so far are things like: keeping it simple, choosing the right terms (shall or should etc), choosing the right format (flow, bullet, etc) advantages of using "white space".....things like that.

Anyway --------

Then I thought of the good ole Cove and wondered if any of you folks have done anything like this...have any tips, outlines, anything that might be useful.
Or - should I forget this idea and just keep slugging forward the way I have been.

Thanks for any help

James
 

John Broomfield

Leader
Super Moderator
Re: Technical writing - hel training supervisors in the basics

One of my tasks is Document control and I am trying to work with our Supervisors and managers to get things properly documented and up to date.
Currently, we tend to ask the supervisor to write things out and then we try to turn this into a controlled document.
Of course this process has a lot of snags (and frustration) when we have to go back and ask questions, get clarifications etc.

I've started writing down some brief "tips" that might be useful for the management people to know and was thinking about making this into a PPT that we could run our management folks through.

Of course I don't expect them to become technical writers. (Hey I need my job.:D) I just think that it would be useful for them to know what kinds of things we look for in a procedure, instruction etc.

Some points that I have touched on so far are things like: keeping it simple, choosing the right terms (shall or should etc), choosing the right format (flow, bullet, etc) advantages of using "white space".....things like that.

Anyway --------

Then I thought of the good ole Cove and wondered if any of you folks have done anything like this...have any tips, outlines, anything that might be useful.
Or - should I forget this idea and just keep slugging forward the way I have been.

Thanks for any help

James

James,

Document what is instead of what should or shall be.

This encourages managers/process owners to focus on the process (aka the work flow).

Define the process objective or the reason for doing the work.

Then flowchart the process as it is to describe who does what to fulfill the process objective (swimlane format works best) instead of trying to write good prose.

Test the flowcharted procedure for uniformity of understanding by its users instead of the quality of writing.

If the process does not exist then design the process but engage the process team members in analyzing how the process actually works and what needs to go into its flowcharted procedure...

...and any supporting documented information such as photographs, video clips and cue cards.

John
 

Wes Bucey

Prophet of Profit
I write a lot. (surprise!)

Different types of documents require different, individualized approaches.

A work instruction really needs two levels of documentation. The high-level (for experienced workers) is essentially a checklist to remind the experienced worker to perform the steps in order and not leave any out.

The basic level is more detailed. Think of this level as for the new worker who has zero prior knowledge of the tools, instruments, materials, and needs to be able to produce the product without an experienced hand to catch mistakes. Thus, this level might include sketches, diagrams, photos, videos, maybe even a "gold standard" model of the product to compare against his effort.

In general use, the document open at the work station would probably be the high-level one, BUT the basic one would be readily available in the drawer if the need might arise. Workers need to know BOTH levels exist and are available.

The supervisor needs to be aware of the :ca: aspect of documentation - that it should include the exceptions as well as the routine.

A purchase order is a document. If we order a commodity, we can give a generic description (1,000 pieces 2 X 4 pine lumber 8 feet long.) If we order a custom product, we need to be much more specific and precise in the description (1,000 pieces 304C stainless steel shafts, 0.500 inch diameter (+/- 0.005 tolerance, Ra 16 microinch), 6.000 inch length (+/- 0.005 tolerance, plus a straightness callout) all accompanied by an engineering drawing properly notated with G D & T per ANSI Y14.5 M.

A contract for building a multimillion dollar jet will probably be more detailed and specific than one for a fifty gallon barrel of cutting fluid for the machine shop.
 
P

PaulJSmith

Re: Technical writing - hel training supervisors in the basics

Document what is instead of what should or shall be.
Oh, that we could get people to understand the simple genius of this basic concept...

That said, it's always helpful to educate your coworkers. Nothing wrong with the idea of a PPT to aid in that. Show them some examples of as-submitted documents vs your edited versions. Give them a basic understanding of what you'd like to see, and tell them why this is helpful.
 
J

JRKH

Great Stuff you guys.

Wes - you hit on an excellent point about getting folks to recognize the :ca: aspect of these things. We've all heard the line "nobody told me that". :rolleyes::notme:
Good documents and training cure that one.

John - Great bullet points to work from - and that's the kind of thing I'm hoping to develop.

J0anne and Pancho, thanks for the links. Good stuff there. :agree1:

James
 
Top Bottom