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: Getting the programmers to come to you From:TIMMERMAN <timmerma -at- IPDLINK -dot- IPD -dot- ANL -dot- GOV> Date:Wed, 12 Mar 1997 14:37:06 CST
David Castro writes ...
Buying a breadmaker and making bread at your cubicle (or in the
kitchenette, or wherever) works at getting the programmers to your cube,
and at your mercy. It's a perfect time to ask them those questions you need
answered, while their mouths water! I highly recommend this technique.
My reply,
Many, many years ago an industrial engineer mentored me (I'm a tech
writer) on how to survive and even stand my ground at the weekly staff
meeting of department managers and VPs (my boss sent me in his stead).
This engineer taught me how to create a task analysis for all aspects
of producing a technical manual, (i.e., identify each task, who's
responsible for each task, when each task is to begin, when each task
is to end, and etc.). Needless to say, many tasks are dependent on
other people (like SMEs). At every staff meeting, I gave everyone a
copy of the updated task analysis. When I gave my status report at
these meetings, I always referred to the task analysis. Any guesses
who everyone looked at when a task wasn't completed on time. It sure
wasn't me. I also didn't have to provide an answer for why those same
tasks were not completed on time; the person responsible had to.
I didn't have to attend very many staff meetings after I started using
this method before I got full cooperation from all departments. My
working relationship with these people also improved and the
importance given to documentation increased greatly. I realize most
of us don't attend these kind of staff meeting (I don't anymore
either) but using a task analysis can really put you in a better
position when everyone is trying to make you the fall guy/gal. It can
also get you more time to produce that tech manual. Just make sure
you use a realistic time schedule.
I just remembered, I had another boss who wouldn't even look at a task
analysis. So, what do ya do? "Never take ownership of a problem that
belongs to someone else."
Don Timmerman, dtimmerman -at- anl -dot- gov
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
