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: A market survey (sort of) From:David Neeley <dbneeley -at- gmail -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Wed, 23 Jun 2010 09:44:28 +0300
I think a key insight into this question was when Dick Hamilton suggested:
> The fatal error that happens over and over is a rush to a software
> solution before the problem is understood. Documentation managers are
> particularly prone to the delusion that acquiring a CMS will somehow
> magically let them avoid the hard work of analyzing their needs, their
> content, and their processes.
I would go farther than that. In my experience with organizations from
the very small to the Fortune 50, the documentation departments often
remind me of the "like Topsy, it just growed" explanations often given
for why things are a nightmare organizationally.
Often, to implement a CMS successfully there must be a total
re-engineering of the entire doc setup--archives, processes,
projects--the whole enchilada.
The kicker is that once you have done this, a CMS itself may become
somewhat redundant, at least until the mess begins to be overwhelming
I think there is a reason that CMS products that originally were
developed for document management have often transitioned into a
larger focus on web content management. Websites tend to become
somewhat all-embracing, needing input and use from people in many
different parts of an organization and often from many different
By contrast, most documentation departments are far more limited in
scope, quite often being self-contained units in limited physical
sites. Most docs, too, are the responsibility of a small team if not a
I participated several times in process re-engineering of doc
departments and their resources. Often, the gains from rationalizing
their operations were very real--but most writers are ill equipped to
handle this kind of work, and most doc managers are promoted from
within the writers' ranks. By taking on a management role, that does
not mean they are automatically skilled in this kind of task if they
have not done it before or have no interest in it.
In my view, a prudent doc manager should always be concerned about
whether their existing processes are adequately serving the needs of
the organization. One useful exercise I have used in several contexts
is to have everyone do a process flow chart of their primary
tasks--even if the "chart" is entirely text. Having a writer detail
the process used for producing a given deliverable can make some
lightbulbs go off as folks begin to realize that they can often do
things far more sensibly and efficiently.
I have described before how I had to rearrange the entire storage
infrastructure of a docs department in the middle of a release cycle,
simply because there was no room on their allotted server resources
for new work to be added. I found an incredible duplication of files,
as each writer had been given directories to work with and there was
no consistent, central repository at all. Even writers who had left
several years before had directories full of copies of various
documents--getting all that straightened out was something of a
nightmare, as was finding canonical versions of various release docs
to create central reference files. In the end, more than 40% of their
server space was freed while the release went out on time, although it
was definitely touch and go for a while there.
For too long, those folks had coasted along oblivious to the
implications of what they were doing and wasting far too much time on
unnecessary struggles with their own lack of rationalized process.
My experience, therefore, tends to confirm what Dick has said.
However, I must admit that for smaller organizations with limited
needs, I still don't quite get what XML brings to the table. Again, it
is a case of discovering what your true requirements are and the best
means of meeting those requirements.
Gain access to everything you need to create and publish information
through multiple channels. Your choice of authoring (and import)
formats with virtually any output. Try Doc-To-Help free for 30-days. http://www.doctohelp.com/
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-