Techwriters in the product development cycle (was Help2)

[Richard Dimock <red -at- ELSEGUNDOCA -dot- ATTGIS -dot- COM>]

Wm. MacLeod asks about where in the product development cycle manuals should be
 developed.


Dick sez:

I totally agree with Lori! Right at the start.

You are looking at a confidence-building process, both for the engineering
side, and for the writing side.  Proceed carefully, be certain to deliver
on promises, and **don't** attack the other side for not delivering.


The BIG FEAR

The main worry the engineers have is that they are feeling their way along,
and need total freedom to change as they go. The last thing engineers want
is to have Pubs people complaining about the changes and writing work wasted.

If you smile cheerfully at change # 3924, and say "Hey! Good Idea!" rather
than dramatically tear up a hardcopy and moan "Back to the drawing board!",
you will become accepted as an ally.

This doesn't mean you just blindly agree with everything. There may be darn
good reasons to fight a change. Bring your user expertise and product
knowledge to the argument.


WARNING!

Warning: The following procedure means many more meetings for Pubs people.
But the meetings are an investment in the future.


SUGGESTED SEQUENCE

A good sequence to follow is:

        Have Pubs Boss ask to sit in on project approval meetings, as an
        observer. This gets the scheduling information early.

        Have Pubs boss sit in on the project management meeting, at the start
        of the project. Or just pick any ongoing project and politely barge
        in. This would be the meeting of department heads cooperating on the
        project. The Pubs boss gets more info about resources needed. The Boss
        can  call it a purely administrative, not technical, presence.

        Meanwhile, back at the Pubs Ranch, the writers are building working
        friendships with engineers. Use the old lollipop for a quick review
        trick, etc. Worm into the lunch bunch. Be seen frequently in the
        engineering areas. Whatever it takes. Y'all know how.

        Pick a project having a really good writer/engineer pair and send the
        writer to the technical meetings. You don't have to wait for a new
        project to start. The books may be in progress. Just get the writer `]  inside
 the meeting room every time. It may not accomplish much at
        first, but results will come. Now you have project # 1 underway.

        Get a writer assigned to a new project, and have the Pubs Boss
        introduce the writer to the engineering leaders. Use the old
        scheduling topics at the first leader meetings. FIND OUT WHEN & WHERE
        THE NEXT PROJECT MEETING WILL BE HELD!

        Have the writer JUST SHOW UP EVERY TIME at the initial project
        planning meetings.  This may be a year or more before writing start.
        Replace the writer if needed, send substitutes when needed, but
        always have that Pubs Presence at the meeting. Project # 2 is
        underway.

Keep at it, covering more and more projects this way until you are on top of
every project.

Be absolutely sure to keep any deadline promises once made. THEY may slip
behind, which is catchup time for Pubs, but never miss a deadline **after**
development is finished.


TRICKS:

Volunteer to be the meeting recorder and get the minutes out fast. Don't worry
about gender issues or secretarial image.  You have a Higher Goal.

Bring donuts for morning meetings and cookies for afternoon meetings. Don't
overdo it, don`t allow ANY appearance of obsequious propitiation.

Your company MAY have some standard that governs how projects are approved,
started, tracked, ended, continued, supported afterwards, etc. Get Pubs
included in this standard. Require Pubs available at formal release, and work
back earlier from there -- final draft date, first draft date, etc -- until
Pubs is in on the project approval point.

These are some of the tactics I have used, and my groups have used, to great
success.  It can be a long haul.


A TALE

My current group has a historical tale of a few years ago about the first time
a writer actually went to the Forbidden Territory of the developer's floor to
ask a question. Verboten! Taboo! Do Not Disturb Engineers!  At first engineers
just gaped at the writer. Muttered news spread. Three or four engineers
approached the writer. AND APPLAUDED! MORE APPLAUSE! CHEERS! A totally
artificial, bonehead management edict of separation came crashing down.


MEETINGS PHILOSOPHY

Personally, as both writer and manager, I always attended whatever meetings I
felt I should be in on. Maybe not the Board of Directors meetings, but, well,
almost any meeting. With the forthright approach, pure intentions and pleasant
smile, I have never been bounced from a meeting.


SUMMARY

Like the fabled camel, get your nose inside the tent.


Regards,


Dick Dimock             Artfully Senior Tech Writer, attending meetings at

AT&T Global Information Solutions       in lovely

El Segundo, CA          Where we hold overlunch meetings to get business
                        done in between meetings.  El Segundo has a nice park
                        where we occasionally have a pizza fest meeting. I
                        have sneaked out to the park with my laptop and
                        written real manual stuff. Between meetings.