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.
> Our major problem is the students' dislike for group work. Because a
> manual is so difficult to mark, our marking load would be helped
> considerably if students worked well in groups. But despite having a
> semester of Group Communication, and lectures on teamwork/group
> processes, the students tend to lack the skill to put aside individual
> differences and time conflicts in order to serve the client.
Marsha --
Here's a great exercise you can do in class to get a lot of insight into
students' teamwork skills. I originally learned this exercise in a project
management class, but I think it's appropriate for technical writers, too.
It's possible to do this exercise in an hour or so ....
First, divide the class into teams of 5 or 6 members by having them
count off (first person says "1," second person says "2," etc.); or use
other method to separate them into random groups (*not* with members
they choose themselves). Next, give each team an identical packet of
tiddly-wink parts (yes, you read that right ... but you can use leggos,
if you prefer). Tell each team to appoint a leader and a scribe. Next,
instruct the team that their mission is to design a launch pad for a
space shuttle. Each launch pad will be judged on the creativity of the
design, innovativeness, simplicity, elegance and, most importantly,
functionality (it must be able to withstand the weight of the spaceship
for 10 seconds). Show the teams a toy spaceship and allow them to analyze
it, measure it, weigh it, and so on. Do *not* let them start building
yet! Give them 10 minutes for planning. Some teams will want to start
building during the planning phase, but do *not* let them start the
building process yet. Insist that they spend the time *planning*. At
the end of the 10 minutes, tell them they have 30 minutes (or 40 minutes,
if you can afford the time) to build and test their launch-pad design.
Now the fun begins .... You'll see some team members who want to take
over, some who are content to simply watch, some who try to propose a
different approach, some who solicit feedback from others, some who
reject others' ideas, and many other indications of their teamwork skills.
After the teams have had a few minutes to work on their designs, you
should select team members who will be "transferred" to other teams.
some will go willingly and, of course, some will go unwillingly; like-
wise, some teams will accept new members and welcome their participation,
and other teams will fail to make new members feel welcome. (Once, when
I did this exercise with a group of high school seniors, one fellow was
so frustrated with his team members that he begged me to transfer him to
another team; my response was that the needs of the business required
his skills on his current assignment. Haven't we all heard a variation
of that before?) After you've mixed up the teams a bit, forcing them to
adjust to the disruption caused by transfers, give them a few minutes to
get more comfortable. Then, just 10-15 minutes before their time is UP,
stop them all -- you have a big announcement: the site of the launch pad
has just changed. Tell them that the new launch pad site will be on the
side of a hill! Use a 3-ring binder to simulate the slope of the hill,
and tell them that the deadline is still the same; they won't get any
extra time to incorporate the new specifications into their designs!
During the last ten minutes of the exercise, turn up the heat by
wandering around, looking over their shoulders, and telling them how
much time they have left. Finally, when time is up, insist that all
teams stop working. Some teams may not have a design ready for testing;
that's okay. Let the teams who feel ready test their designs while
everyone counts down ("10, 9, 8 ...."). Some designs will probably fail
and some won't. That's okay, too. The *real* point of this exercise is
to simulate a project development cycle and to let them see how they and
others function within a team. Make sure you have enough time after the
exercise for everyone to discuss their experiences and insights (a post-
mortem report).
Trust me ... this is one exercise your students will *never* forget!
And, better yet, they'll learn a lot from it.
BTW, here's a book recommendation for you: _Team Players and Teamwork:
The New Competitive Business Strategy_ by Glenn M. Parker (ISBN:
1-55542-257-8).
Lori Lathrop ----------> INTERNET:76620 -dot- 456 -at- compuserve -dot- com
Lathrop Media Services, P.O. Box 808, Georgetown, CO 80444
