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.
Thank you to everyone who replied to my post, both on and offline.
Here's a summary of the comments (and my responses, where appropriate).
Warning ? very long!
Documentation is the author's responsibility
------------------------------------------------------------
I couldn't agree more. If I as the author don't care, then no-one will. It
is because I care about documentation that I find my work situation so
challenging.
Documentation is not valued ?Make them see the value of documentation
(through doing)
-----------------------------------------------------------------------------------------------------------------------------
This is a difficult one ? something I thought I had achieved. Several months
ago (when we were first amalgamating with another company), we had two main
products: one which I had documented (product 1) and the second which had
existing (but very poor) documentation (product 2). Our support team was
very new to both products and used the documentation extensively. Their
feedback (via management) was that product 1 was very easy to support (and
hence required less time and less resources), whereas product 2 was very
difficult, as there was no information for them to go on.
Now that I have fully documented product 2, I have received positive
feedback from various people (our Japanese agents, the CEO himself) as to
the effectiveness of the documentation.
In addition, the developers now use the documentation to check product
functionality, rather than looking through undocumented source code.
Having said that, neither management nor the developers themselves consider
it necessary to communicate to me product changes/developments or company
guidelines, or provide other support (such as reviews) to keep the
documentation up to date.
Obtaining information - suggestions
-------------------------------------------------
- develop rapport
- be assertive (politely)
- be persistent
I have tried everything in my armoury to get the information I need (and
having worked as a tech writer for more years than I care to remember, I
have developed quite a few approaches :) )
Although I get on fine with the developers, no amount of cajoling, treats,
threats, appeals to intelligence or sense of worth as human beings,
expectation of positive results (in the hope that they will live up to
them), even 'guilt tripping' has a lasting effect. Daily prompting to
include me in the distribution of builds/release notes works only for a
short time.
- get on mailing lists
Curiously, this has proven extremely difficult. There seems to be a real
reluctance to have me included on dev emails and I can't for the life of me
think why.
-review product /become SME
This is my current mode of working. This is NOT ideal ? it is possible to
miss important information
- obtain the source code and check documents
Not feasible as the source code in NOT documented
- get a copy of the product launch calendar
This one gave me a good laugh. Product launches occur as and when management
decree (i.e. often in response to competitor product releases). Needless to
say there is no documented plan.
Take charge ? make policy/define process, and make it stick (aka 'don't ask,
assertively request')
-------------------------------------------------------------------------------------------------------------------------------------
This is good advice, and something I always do (within my sphere of
authority)
In situations where my work environment is not defined, my assumption is 'do
until you are told otherwise'.
In my current role, it seems I have no authority. I can plan and develop
processes as much as I like (including metrics and the measures of the
'value' of documentation). What I can't seem to do is get acceptance or
support for my policies/processes. I have discussed this with both
development managers ? both pay lip service to the documentation yet neither
are prepared to put in any practical support.
Putting in place a 'policy' without support is akin to having no policy at
all. All this will achieve will be to make documentation 'too difficult'.
Talk with your supervisor/manager/ VP
------------------------------------------------------
See above point. My supervisor/manager/VP are one and the same!
Thank you for all your comments. My approach will be to try and get further
clarification of my duties and failing that, to move on. I will forward
progress to this list if anything occurs.
ROBOHELP X5 - SEE THE ALL NEW ROBOHELP X5 IN ACTION!
RoboHelp X5 is a giant leap forward in Help authoring technology, featuring all new Word 2003 support, Content Management, Multi-Author support, PDF and XML support and much more! View an online demo: http://www.macromedia.com/go/techwrldemo
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
