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.
Re: Justification/Tech Writer Role/Non-Profit Development Team
Subject:Re: Justification/Tech Writer Role/Non-Profit Development Team From:David Neeley <dbneeley -at- oddpost -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 19 Dec 2003 14:59:16 -0800 (PST)
John,
Unless I'm missing something, the usual litany is *NOT* involved here. You said:
"From a business justification standpoint, neither of these,
and nothing LIKE these are the justification. The
justification must be one or more of the following:
-Save real money
-Make real money
-Gain marketshare
-Gain a competitive advantage
-Protect against legal action (see the first item)
-Comply with regulatory requirements"
>From the subject of the thread, this is going on in a nonprofit organization. Thus, any justification has to be strictly on a basis of costs and resulting in a program that will be easier and cheaper to use and maintain.
Personally, if faced with this question, I would quietly do a little background on the new development manager and try to find out the quality and usefulness of documentation in *those* projects. Unless I miss my guess, it is probably execrable. While it would be terrible human relations to say so outright, at least you would gain a concept of the expectations that person has.
Then, I'd build a doc plan that would speak to the direct interests of the developers and of the client organization. In this plan, I'd include references to clearly articulating user requirements at an early phase of the project to save unnecessary mistakes (especially since developers rarely understand client needs) and the fact that the tech writer is in a good position to determine at an early stage whether any developers or development teams are departing from the development plan--again, in time to serve as a "trip wire" for the project's manager.
Finally, I'd point out that extensive running of the code as various pieces are usable will tend to wring out many of the bugs--serving as a cost-efficient adjunct to the QA people.
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4
---
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.
