RE: Teaching others how to fish

["Lauren" <lt34 -at- csus -dot- edu>]

I've never really found one thing that works for all of my contracts, but I
do routinely create templates for the common types of documents at each of
my jobs.  Occasionally, when I have the time, I will make a template that is
accompanied by a set of instructions prepared with the template.  Sort of
like, "*Introduction* Use the introduction to describe the purpose of
process and introduce it with, 'The purpose of this process is to...'."  

I also provide guidelines for how to get information that is required for
the different sections of the template and I discuss what information the
sections should and should not contain.  I rarely have enough time to
produce writing instructions because my jobs are short, but the template is
something that I need to produce my work and it helps the people that I work
with, so I leave the template as a project deliverable.

It is also a good idea to provide writing guidelines, like a mini-style
guide, of issues that are particularly annoying and should be avoided but
pop up anyway.  It's best if the guideline is one page and can be tacked to
a wall for reference.  Include methods that cover handling of issues like
writing in all caps, references to people rather than job titles, and
failure to provide full access to information.  I once had a job where the
command was to "double-click the application icon."  Well, I didn't have
this icon.  It was apparently a link to some sort of mainframe database.

"Oh.  I'll email it to you."  
"The link you sent didn't work."  
"I guess you don't have access."  
"So how can I write the document?"  
"Use my computer after I leave."

I still felt like I was missing key information, but SMEs will make
assumptions about the audience that need to be addressed in the document, so
thorough information is essential.

People have asked me if they should write something up for me.  The hassle
of fixing another person's work, especially when that person does not want
to write, is more of a problem then getting the information myself from
shadowing people, conducting interviews, and following the processes myself.
These days I prefer that there be nothing to work with, rather than have
somebody that doesn't write, try to write.

Lauren
 

> -----Original Message-----
> From: techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com 
> [mailto:techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com] On 
> Behalf Of Daniel Ng
> Sent: Friday, July 20, 2007 4:17 AM
> To: techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: Teaching others how to fish
> 
> Hi!
> Documentation development is not the work of one but to be successful
> for an organization it has to be a continuous process by all in
> organization.
> 
> How do you improve the written and quality of technical 
> communication in
> an organization?
> 
> As more documents need to be completed by a pro writer, I find that I
> end up doing more time doing lots of content editing, 
> restructuring and
> reformatting. 
> 
> * Do you hold classes in your organization to better improve 
> the written
> communication of documents written by non-writers ie 
> engineers, project
> managers? 
> 
> 
> Typically, these are the ppl on the customer facing sites who 
> may better
> service the organization if they write the documents themselves first,
> instead of putting a request and waiting for the queue to be 
> fulfilled.
> However we end up getting these documents later on and then trying our
> best to reformat it agains't the house style..couldn't our time be
> better used.
> 
> * What other methods have you done to improve how your time is spent?
> 
> 
> It seems all these things we are resolving are more symptomatic in
> nature and not really improving the quality of things on a 
> larger level.
> 
> Where writers are very limited in number, finding writers to fill the
> growing number of requests is pretty hard. 
> 
> 
> 
> 
> Daniel Ng
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Create HTML or Microsoft Word content and convert to Help 
> file formats or 
> printed documentation. Features include support for Windows 
> Vista & 2007 
> Microsoft Office, team authoring, plus more.
> http://www.DocToHelp.com/TechwrlList
> 
> True single source, conditional content, PDF export, modular help.
> Help & Manual is the most powerful authoring tool for technical
> documentation. Boost your productivity! http://www.helpandmanual.com
> 
> ---
> You are currently subscribed to TECHWR-L as lt34 -at- csus -dot- edu -dot- 
> 
> To unsubscribe send a blank email to 
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit 
> http://lists.techwr-l.com/mailman/options/techwr-l/lt34%40csus.edu
> 
> 
> To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com
> 
> Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
> http://www.techwr-l.com/ for more resources and info.

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

Create HTML or Microsoft Word content and convert to Help file formats or 
printed documentation. Features include support for Windows Vista & 2007 
Microsoft Office, team authoring, plus more.
http://www.DocToHelp.com/TechwrlList

True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/ for more resources and info.