TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Making group work palatable From:"Eric J. Ray" <ejray -at- RAYCOMM -dot- COM> Date:Wed, 4 Dec 1996 06:24:01 PST
A couple of thoughts about collaboration:
My experience is that collaboration in the "real world"
occurs primarily when, for some reason, the individuals
could not accomplish the project on their own, due
to skill, experience, or time constraints. Artificially
telling students to work together because it will
be good for them isn't, IMHO, likely to succeed.
I've had the best experiences in real world collaboration
with short term, intense projects in which the
skills of the collaborators are complementary.
Last year I worked on an intensive training program
with another tech writer. We had about one week
to learn a cobbled-together system and the related
systems, to develop a training/documentation program, and to present
a pilot class. It worked out very well from the collaboration
standpoint because my colleague had extensive instructional
design experience while I had the tech writing experience.
I had more background and understanding of the systems,
while he knew more about the needs of the audience and
had a better grasp of the potential problems.
We both desperately needed the skills the other
one brought to the task and while either of us could
have done it, there's no way that we could have done
it effectively, in time, working alone.
Synthesizing that environment might require multiple
short projects or a different approach, but would benefit
Eric J. Ray ejray -at- raycomm -dot- com