Presentation on the documentation process?

["Geoff Hart" <geoff-h -at- mtl -dot- feric -dot- ca>]

Krista Van Laan is <<...going to give a presentation on the
documentation process to the engineers and probably some 
marketing people. Has anyone had any luck doing the same 
thing or any ideas on how to make it interesting?>>

Make the meeting interactive, and fill it with the kinds of 
twiddly things engineers like to play with. And make it a 
visceral lesson in how the current documentation process 
makes it tough to get your job done. Here's one way you 
could do this:

Bring a pile of Lego to the meeting, and place it on a table in 
the midst of the engineers. Make sure it's not sorted into 
anything approximating a useful order (e.g., don't put all the 
long ones in one pile, all the short ones in another). Remove a 
few key pieces that are necessary for the project. Display a 
functional specifications document for something moderately 
complex, but that could be built in about 5 minutes, and tell 
them whoever can build the thing first gets bragging rights in 
the staff newsletter plus something more tangible such as a 
box of Godiva's chocolates (or whatever other prize you think 
will motivate them...Pokemon cards, if that's what turns them 
on).

Give them a few moments to scramble and fight each other 
for access to the box of Lego. Keep a close eye on things, 
and when one of them looks like they're approximately 
finished (they can't actually finish, since you've hidden those 
few key parts), have your companion stop them all and claim 
that there's been a change in specs: "Wait, I just had a better 
idea!" Put up a new specification that requires them to tear 
apart most of what they've already built, and reassemble it 
into something new; specify a different color of Lego, or 
double the size of the product.

Again, when they're getting close, interrupt them: "Sorry 
guys: just got new marching orders from marketing..." Put up 
another specification, much like the original one, but bigger, 
and this time one something that doesn't require them to use 
the missing components. Let one of them finish this time. 
Bring your champion up to the front of the hall, start to hand 
over the prize, then have your companion snatch it away 
again. "Sorry... we need to add wheels to it now!" After 
everyone laughs, relent and let the poor sap have the prize.

This pretty much covers the whole documentation cycle: 
changing specifications, last-minute additions after the docs 
have been frozen, creeping featuritis, and inadequate 
resources. If you really want to be cruel, add in peer review 
and let the other engineers tear apart the finished model (e.g., 
"it's all different colors: make it again in red only", "no, I like 
the rainbow effect better", "wait a minute, you missed a two-
bump Lego here...", etc.).

Even if they don't learn anything from the process, think how 
much fun you'll have watching them do what you do for a 
living. <eg>

--Geoff Hart @8^{)}  geoff-h -at- mtl -dot- feric -dot- ca  (Pointe-Claire, Quebec)
"Perhaps there is something deep and profound behind all those sevens, something just calling out for us to discover it. But I 
suspect 
that it is only a pernicious, Pythagorean coincidence." George Miller, "The Magical Number Seven" (1956)