Re: Passing the Flame

[John Cornellier <tw -at- cornellier -dot- com>]

> I'm leaving my current job, and have been asked to write a document
> which provides information on the documentation set (PDF & online help)
> that I'm leaving behind. This document is intended for the technical
> writer who will replace me (I won't get to meet him/her before I leave).

Having been through the legacy-handover-grinder more than once recently, I now document what I do, as I do it. (Sorry Manjeet, I know this isn't helpful to you now, it's just a comment). The idea is, when you do go you don't have to spend your last few weeks doing this sort of thing. It's also a useful exercise for getting an objective view of what you do.

Set up a documentation home page on your corporate intranet.
* If you have files you use, put 'em in a public space and put links to them, rather than on your local disk.
* Document the evolution of your templates and documents with links to your EDMS system, if any.
* Publish your planning and your bugfix lists.
* Any reports/memos about the state of the doc or your plans, put 'em on the web (tip: don't just use the web as a document interface linking to a load of PPTs, DOCs, and PDFs, convert to HTML where poss, out of consideration for future generations).
* If you have URLs you use in your work, put them there, rather than in your browser bookmarks.

The above is not actually much extra work, usually you can reuse stuff from your planning, monthly reports, etc. On the other hand, it shouldn't become an end in itself. Keep it quick and dirty. Don't get obsessed with it being representative of your work. Your work is producing docs. This is metawork.

Having moved around a bit recently, I've been at both the sending and receiving end of this. Something I find quite useful where there is a lot of legacy doc is some historical perspective of how things got the way they were, as in the following scenario.

1. In Ye Golden Age, everything was written in Ventura 1.0 for DOS by a team of experienced TWs in the Engineering Dept. in Fargo, North Dakota. The documents were backed up on 295 5 1/4in floppies.
2. There was an R&D initiative to move everything to SGML in 199x. The budget was spent, the files were converted, but the implementation never went through as there was no user demand, no business case, no added value....
3. After the collapse of pork futures in 199x all the TWs were sacked. 
4. A few years later clients started to complain about the outdated doc so cowboys were brought in by the marketing department. Cowgirls too. The 295 5 1/4in floppies having been used to shingle an outhouse in Monango, they salvaged the SGML into HTML 1.0, thence to Word 2.0. Except for the stuff they got OCR'd by some interns.
5. R&D got fed up with all this and hired new TWs, who moved everything to Adobe products on Mac OS.
5b. And so on.

The point is, sometimes things are done which "seemed like a good idea at the time" but are hard to fathom later.

John


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY.
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Take XML and Tech Writing courses online!  Our instructor-led courses
(4-6 hrs/wk) give you "hands on" experience at your convenience. STC members
get 20% off!  http://www.online-learning.com/index.html.
---
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.