What is the difference between good (technical) documentation and good training? 
(also, please state how documentation and training differ). 
(We are currently documenting our technical systems at work and we
have very little documentation yet we must document the system quickly
and of that produce training materials - in document format. We are IT
software department, small one, informal environment),

Hello Ianp,

As you ask, let us first look at the differences between good
technical documentation and good training. A good way to start is to
enter the following search phrases
  define documentation  (or define:Documentation)
  define training       (or define:Training)
to see the kinds of references / definitions are brought up. Here is a
brief synopsis of some of those defintions:

Documentation
=============

Material that clarifies or gives instruction in the operation of a program.
  http://www.oznet.ksu.edu/ed_asi490/Glossary/cgw.htm
The printed or online documents that explain things: identify the
parts of your hardware or software, give installation instructions,
give directions for use. In programming this includes explanations of
the code - why it is written that way, what the code is doing.
  http://www.jegsworks.com/Lessons/reference/glossary-noframes.htm
The process of recording the model equations, rationale, data sources,
variables, code and experiments for purposes of information
transmission.
  http://www.pestmanagement.co.uk/library/gloss_d2.html

Training
========
Activity leading to skilled behavior
  http://www.cogsci.princeton.edu/cgi-bin/webwn?stage=1&word=training
... planned activities which support and improve individual and
organizational performance and effectiveness
  http://www.usdoj.gov/jmd/ps/appendix1.htm
Instruction which emphasizes job-specific, near-transfer learning
objectives; traditionally skills-based instruction, as opposed to
education
  http://citl.tamu.edu/citl-glossary-main.htm

There are a number of additional definitions for both terms. Note the
focus for documentation is description, clarification, or explanation.
The focus on training is the improvement of skills or performance.

So when looking at IT (or software) documentation the focus tends to be on the:
 - design or architecture
 - instructions for installation or "how to use" some menu / display
 - background data / sources so when conditions change, you can revise
the program to address those changed conditions.

The IT (or software) training needs to focus on:
 - introduction to the system (or background material)
 - explain the whole process such as...
  o external steps leading to ...
  o to do task "X", perform these steps
  o external steps following use of the system
 - THAT happened, what do I do NOW?
 - practice the methods to turn them into learned skills
Training (and training materials) should be more focused on "getting
the job done" using the software.

Note that the "document format" for training can be quite flexible
without a lot of effort. An example I found while researching this
question included:
  http://www.free-training.com/osha/forklift/forkmenu.htm
This is a series of linked web pages that 
 - provide some introductory material
 - have a few questions / answers mixed in with explanatory material
 - a test w/ scoring
Yes - this is training for operating forklifts and does not train the
operator for a specific machine / situation but does provide general
training and certification for employers. It satisfies a "general
knowedge" or understanding objective but not objectives for specific
knowlege (e.g., operating a PE30Y Nissan Forklift).

Don't forget you can also provide items such as:
 - job aids - a one page description of a task
 - keyboard templates / menu explanations
 - "Frequently Asked Questions" (with answers)
 - a GOOD on line help system w/ task oriented contents and search
One or more of these can be used to help train (or remind staff) on
how to use the system.

The overall "training process" is described quite well at
  http://www.optimum-learning.ltd.uk/pdf/TTTMar2000.pdf
but I believe this is a lot more than you want to address. There are
however a number of good suggestions in this short document that you
can adopt without too much cost or effort. For example, if you do some
simple task oriented analysis, define objectives, and THEN define the
training to provide, you should get good training materials without
any wasted effort.

A few other resources I found while searching included:
  http://www.wbtic.com/primer.aspx
a "primer" on web based training
  http://learninglab.oreilly.com/
where you may want to contrast the "resource centers" (technical
documentation) on the left side with the training courses in the
middle / right side. All are software topics.
  http://www.trainingplace.com/source/thelist.html
a mailing list for web based on line training
  http://coe.sdsu.edu/eet/Articles/jaortrain/start.htm
a quick comparison of when to use job aids or training. In particular,
check the "solutions" to the training problems.

Additional search phrases included:
  free web based training
  training "skills gap" "needs analysis" delivery process
  job aid training

If you would like me to expand the answer on some specific topic or if
some part of this is unclear, please use a clarification request.

Good luck with your training.
 
  --Maniac

Took a wide perspective on the question. Thank you. Perhaps you could
have tackled the difference between good doc and good training better
at end of answer but for 10 dollars a fair answer.

Good technical documentation is straight forward, easy to read and
provides all the information you need to understand what it is
describing. Documentation typically just describes the 'what', it
gives information on what the product/function/feature is, what it's
arguments are and possibly how it relates to other features etc.

Training really focuses on the 'how': how to use a
product/function/feature, how that function will be used to accomplish
a task, how to produce the desired results etc.

In both examples you need to focus on the fact that people who are
reading your documentation and training material don't know anything
about your product. That doesn't mean you have to treat the reader
like a 3 year old, but it does mean you might need to fill in more
background information than you might think since you have a lot of
history with the product.

forge

forgey

If I may, documentation is good if you don't have a person who knows
how the thing works. It's also good to record those esoteric
eccentricities that happen when you do x. Or how to get y to happen.

Training does the same thing, only in (possibly) terse format, and is
biased to the trainer (If the trainer hasn't fun with the product,
likely the trainee will retain that bias). Documentation will always
tell how it is supposed to work. Training will tell you how it works
for the trainer.  :)

Trainers die, move, are terminated, ... documentation is "forever" :).

And--

Documentation is addressed to a broad audience of users; training may
focus on a particular segment.

Documentation is likely to be function-oriented; training is likely to
be task-oriented.

Documentation is typically unidirectional; training is typically interactive.

Documentation should explain everything the user needs to know about
the product (which is *definitely* not the same thing as everything
there is to know or everything the developers want to call attention
to); training lays down fundamental principles of operation and may
leave the finer points and more specialized or esoteric subject matter
to the user to learn later on his or her own.

Documentation may serve the primary function of being a reference;
training may have operation as the primary function.

And, most basically, unless you are talking about programmed
instruction, documentation is designed for delivery through the medium
of written matter, whether print, HTML, or XML; training is designed
for delivery by a leader in a live or videotaped setting.  The medium
of delivery is the primary determinant of the difference.

As for what makes them good, the same things make them good.

Archae0pteryx

P.S. to ianp-ga:  Very important:  hire a real writer!  Do not let
engineers do the documentation.  Repeat:  do not let engineers do the
documentation.

Hire someone who knows what needs to be done and can tell you what it
is, not someone who has to ask you.

When you look at writing samples, ask if there was an editor involved;
a good editor makes a writer look great without leaving her own
fingerprints on the work.  If the doc's been well edited, though, it
will be very hard for you to tell what the writer can do on his or her
own.  You might need to give the candidate a practical test under your
nose.  Have it rated by someone who writes and/or edits good technical
documentation.  Have the content checked by an engineer, but do not
rely on the engineer for an evaluation of the writing itself. 
Engineers are not editors or writing critics.

You can find writing contractors to do this.  Where are you located? 
Silicon Valley is loaded with out-of-work technical doc people,
victims of the dot-com bust.  But do be careful because there is no
such thing as a writer's license, and a lot of people who think they
can do it really aren't qualified at all, including many people who
have "technical writer" on their resumes.

Voice of experience.

Archae0pteryx
Publications professional (but not a researcher)