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.
Subject:RE: Bad Documentation and Linux From:David Neeley <dbneeley -at- gmail -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Tue, 8 Dec 2009 08:35:46 +0200
From: "Jon Leer" <jleer -at- leertech -dot- net>
<And while you're at how about management giving me a budget? When it comes
<to dealing with upper management it downs to cost first, and ROI second.
That has not been my experience, exactly. Generally, if something has a ROI
in a reasonable time, it is approved. That "reasonable time" may vary from
firm to firm, but is generally at least one year and may be three or more.
The only exceptions are when the cost involved is high enough that it takes
higher levels of management for approval, or when existing budgets of the
department, division, or company will not stretch enough to cover it. With
an expected large payoff, though, it is often included in the next fiscal
period's budget.
The rub with documentation, though, is that it's so often difficult to show
actual ROI to begin with. Benefits such as reduced tech support costs become
very difficult to attribute to the documentation itself.
One good situation is where you can work with a training department to show
reduced training costs and better customer acceptance. That is a more
quantifiable kind of number than most others in the docs world.
(I have worked in non-doc areas in a consulting capacity from time to time,
so I have participated in projects with more clear ROI numbers).
As I think we're all aware, most management regards documentation as a
necessary evil that detracts from the bottom line, not adds to it.
That reminds me of an anecdote a long-time executive with Texas Instruments
shared at a meeting of the DFW chapter of the STG one time. He said that
some years ago now, a survey of TI customers was made, asking them why they
chose TI microcircuits instead of those of their primary competitors. The
number one response by far was that the product documentation was so good
that the OEM customer knew exactly how to best incorporate the parts in
their designs.
He said that for the next three years or so, the docs department was really
flying high--until, eventually, things returned to normal as the lessons of
that survey were forgotten.
David
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Are you looking for one documentation tool that does it all? Author,
build, test, and publish your Help files with just one easy-to-use tool.
Try the latest Doc-To-Help 2009 v3 risk-free for 30-days at: http://www.doctohelp.com/
Help & Manual 5: The all-in-one help authoring tool. True single- sourcing --
generate 8 different formats and as many different versions as you need
from just one project. Fast and intuitive. http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
