Re: Justification/Tech Writer Role/Non-Profit Development Team

[rushsm -at- comcast -dot- net]

Hmm. While John makes good points, as usual, I think Bobby is looking for more concrete suggestions.  I have a couple of comments that may be useful.

12-18 months is pretty far out if we're just talking about making sure a tech writer is up to speed when it counts. There will be way too many changes between now and rollout.But if you can find other ways to justify your presence, this one makes a good supporting argument.

First thing you should do is find out if the new dev manager has worked in an environment where tech writers assist with internal documentation. I recently worked for a company in which all internal docs were the responsibility of the people needing them, such as devs and program managers. So it's possible that this manager doesn't recognize the possible usefulness a tech writer can provide here. 

But in any case, here are some documentation needs a tech writer might be able to help with. Of course the primary argument is that any work a tech writer does frees the devs for other work.

1. software requirements and specifications (usually you won't write these, but instead edit and prepare for publication). It is in everyone's best interest to have clear, well-written, and well-organized source documents. Since these documents change through the lifecycle, you might be tasked with documenting changes and keeping the (internally) published docs up to date. (It really is valuable for a team to work from a common set of updated source docs.)

2. public relations/marketing documents. Not having any details about the project, it's possible there may be a need to inform interested outside parties about progress of the project. May be press releases, articles (library journals?), etc. If there's a PR or Marketing staff, you could offer editing services. Also, a tech writer can be a valuable conduit between dev and marketing teams. Often they don't/can't talk to each other, which often means Marketing ends up uninformed or, worse, misinformed about relevant details.

3. usability. This is not strictly writing, but many tech writers have skills and talents that make them good at gathering usability information. You might get involved in interviewing potential users, possibly in UI design. Certainly this will be valuable information for documentation, but at this early stage that's not a valid argument unless you can contribute in other ways. You might end up writing usability scenarios, developing questionaires, or doing research on the potential audience.

4. It wasn't clear, but do you have a release schedule? Does the 12-18 involve more than one beta and one final release?  Of course, if the first beta is scheduled to go out with documentation in, say 6 months, then maybe you're not as premature as we've been assuming, depending on the scope of the project. As a rough estimate, it's common for a tech writer to get involved 3 or 4 months prior to release, of course to minimize the documentation time needed after code freeze and testing.

In any case, if the projct has an phase release schedule, then you need to be sitting down with your boss to determine how much documentation needs to go out and when. It may be that no one's yet posed this question. If they're planning on doing extensive beta testing, multiple beta session, to different audiences or for different functionality, then you need to have a plan in place. Once you start talking specifics like this, it becomes quite clear to everyone, including you, what you'll be spending your time on. (In case you haven't noticed, it very common for managers to forget to plan for documentation until the last minute.)

Good luck. Oh, and btw, I also had some trouble understanding your "identified statements". Use of obfuscating constructions does not necessarily make the points sound more important.

--
Sella Rush
Seattle, WA
rushsm -at- comcast -dot- net

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP FOR FRAMEMAKER TRIAL NOW AVAILABLE!

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.