RE: Justifying a technical writer

[Suzette Seveny <sseveny -at- petvalu -dot- com>]

Brenda,

I am a technical writer for a retail company.  All of the documentation I 
develop is for in-house users - perhaps not a dissimilar situation to yours. 
 Here are some easy arguments for a technical writer.

Why shouldn't a programmer write the documentation?
1) Because they don't have time - (the proof is how out of date your current 
docs are)
2) They are too far removed from the end user. Most technical writers can 
translate technospeak into everyday language that the average user can 
understand. Few programmers have that skill - especially if English is not 
their first language.
3) Hate to mention this - but programmers earn more than technical writers. If 
each programmer spends ten percent of their time documenting systems, a 
technical writer can document the work of eight to 10 programmers, at less 
cost.  That's logical.
4) A technical writer ensures uniformity across all systems, regardless of 
programmer.
5) A technical writer doubles as a QA tester - potentially catching 
embarrassing errors in the applications.

Why you need to document systems:
1) So end users can understand and take advantage of the full functionality of 
an application. You would be surprised how many people continue to do things 
manually, because they either are not aware the application exists, or is 
contains a particular function.
2) When developers leave, existing documents play an integral role in the 
initiation of replacement programmers.
3) When revising/updating applications, existing documentation can alert you to 
potential interfaces to other systems/applications, highlighting possible 
implications and/or conflicts.

Looking at this mainly from a user perspective, complete documentation allows 
users to complete their tasks in a prescribed manner, in an efficient and time 
effective manner, thereby reducing workload, and improving return on 
investment. Effective user documentation also results in less calls to support 
personnel/help desks, reducing those costs as well. Good documentation provides 
management with an overview of current systems and capabilities, as well as 
other programmers who may need to know file layouts, etc.

Hope some of this helps,

Suzette Seveny
Markham, Ontario, Canada
sseveny -at- petvalu -dot- com or suzette -at- yesic -dot- com
------------------------------------------------------------------
DISCLAIMER:
Any opinions expressed are MY opinions.
Feel free to have your own.
Let's agree to disagree
But Please - Don't Flame Me.

The optimist says the glass is half full. The pessimist says the
glass is half empty. The engineer says the glass is twice as big
as it needs to be.

On Tuesday, May 30, 2000 9:00 AM, Brenda Duncanson 
[SMTP:Brenda_Duncanson -at- mtha -dot- gov -dot- on -dot- ca] wrote:
> I am a Business Systems Analyst in the IT dept of our organization.  We have
> recently had a change of top management and now I need to justify why our
> programmers can't and shouldn't write the documentation [we are years out of
> date].
>
> I have been asked to write a justification for hiring a tech writer to
> document our systems - we are in dire need but have to convince the higher
> ups of this need.
>