[no subject]

Susan Gallagher offered
document archival/versioning/numbering - Document release procedures -
Editing checklists - Style guide/terms lists - and Microsoft Manual of
Style for Technical Publications ( I have incorporated these into short and
long term plans - got the book and it's good)

Michael Collier commented on
needing management backing and support; demonstrate accomplishments; solve
urgent problems; get support from knowledge base experts; and that
information and knowledge are a valuable asset to a company (excellent);
and make information accessible.

Colleen Adams contributed a copy of a memo explaining what TW is and how
she could benefit the company and
doing before-and-after of a document to show the improvements. (A job well
done, she now has 6 people working for her!);
get Hackos' book - get 2 copies even, so you can have one at home!

From John Posada  (you have reason to be proud of it)
demonstrate benefits; find an ally; take existing eclectic materials and
convert it into a uniform, usable collection; let the style guide evolve;
JUST DO IT; get stuff under peoples' noses; keep an ear open if I hear a
programmer having a problem on a subject I have documented - get it to the
programmer! volunteer my writing services; REAL STUFF - not plans;
processes will evolve; put distinctive covers (headings, etc) on documents
that I do to get documents noticed; GET THE STUFF OUT THERE; use new
distribution method (gets attention, too), and SELL, SELL, SELL. (hey John,
bet your not an introvert! - oops, let's not start that one again!)

Jill Burgchardt hit a new target with:
do a requirements analysis; determine what the users need now;
collection-cataloging-cleanup-standardizing as a long term project; don't
try to make documentation mandatory - could be counterproductive; quickly
benefit the people I need to work with; and use John Posada's approach.

Katherine Skilton offered a great idea:
hand the group a piece of equipment they don't understand and tell them to
assemble it without instructions! This will show them the importance of
documentation. They may not change the way they think, so I will have to
change mine without management support, so focus on documentation and not
on plans; show how good documentation provides the customer's answers and
elimnates many phone calls.

From Kimberly Ferri Cakebread
demonstrate that the programmers save time if the TW is doing the
documentation and not themselves; use food bribes - yum, yum, yum for the
brownies.


Bill Sullivan offered good advise
ditto on Hacko's book; patience and persistence - somebody had the good
sense to hire me, a TW, so the old ways must not be working; recall tales
where patience and persistence have paid off; HUMOR; the We-Team and not
the Them-vs-Me.

From Sella Rush
ditto John Posada's comments; do the work and they will come around; find
out their documentation needs and expectations and do the work they want
done - get fast results to them; processes/procedures/ etc are good, but
not the first place to start.

Fabien Vais commented
produce NOW; format and style guides can come later; WRITE; become a
wordsmith for co-workers; PRODUCE and the infrstructure will come later.

Margie offered
profits and losses - quantify, predict, or suggest quantification of the
savings TWing will bring in personnel hours, service calls, and complaint
resolution, etc; take baby steps - incremental accomplishments through
planning.