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.
Lorraine queried:
> By next Tuesday, I have to come up with some ideas for
> documenting a work process. (This is about how other
> departments at our company make requests for software
> enhancements, or report bugs, or other ad hoc requests. The
> process now is that they interrupt QA people and/or
> programmers and the squeakiest wheel gets the grease.) Our
> company is implementing an intranet tool that they will use
> to make the requests, with a back-end that we will use to see
> what's in the pipeline and manage it.
By "documenting a work process" I take this to mean
that you need to document the current process, not
just create a process for everyone to then follow.
A very different animal.
Get a pad of paper, a lot of patience, a whole heaping
load of anti-laughing pills, and start interviewing
people. What you are trying to find out is how people
are doing things NOW, not some idealistic vision of
how they SHOULD be doing things. This is where the
anti-laughing pills should kick in. Follow the
information from it's generation to implementation.
Do NOT treat the very weird, convoluted, stupid and
silly processes people currently use as something to
dismiss. They use the process, right or wrong, and
will defend it to the bitter end. Your task is simply
to capture the process, without emotion or opinion.
Dragging this out of people takes a lot of patience and
explaining WHY you are doing it. After you have this
information, THEN ask them what process they think would
be better.
After you have compiled all of this information, then
look at what the suggested processes the tool supports.
Tools are tools, they are not a process, they are part
of the process, it's the information being passed on
from one person to another that is the process.
Tools aren't perfect, and won't solve everything, but
they are supposed make your process work better.
Armed with the current processes, work with people
to define a new process that accommodates both existing
processes (the ones that make sense), and the new tool.
This will be a big change, and to succeed, will need
visible support from upper management, for there WILL
be resistance to change.
My experience has been with large companies and with
a smaller company, changes like this may be easier,
but this is what I have seen and done with success.
Hmmm, gathering information from the SME's, compiling it,
making sense of it all, and putting it in a format that
others can use, sounds sorta familiar . . . . I wonder
where I've seen this before :)
CB
--
Surfy! http://www.surfy.net Great web search, free web email, and $9.95 unlimited Internet access
Powered by Outblaze
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out the new release of RoboDemo, our easy-to-use tutorial software.
Plus, buy RoboHelp Office in August and save $100 with our mail-in rebate.
Get details and download free trial versions at http://www.ehelp.com/techwr-l
Absolutely FREE! FrameMaker/Win 6 & 7 Express Customization (v3):
Quick-access buttons & keys to common functions, char tag/font drop-down
lists, charset browser, QRef guides & much more: http://www.microtype.com/2
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
