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.
> Tim Altom <taltom -at- iquest -dot- net> writes:
> You've struck the lost chord, Chet. Even creating up-front processes for
> SGML, regardless of future savings, are usually considered too costly.
> Clients listen eagerly to us until the price pops up, then they rapidly lose
> interest. We've even offered to do cost analysis to justify going to a
> database style, only to be rebuffed.
> >
Could this have been because the same result (from the point
of view of the client) could have been achieved more quickly and
in a less costly manner by using well known publishing packages,
styles, templates, etc. (in FrameMaker, Interleaf, or even Word)
than becoming involved in the more labor intensive effort of creating
an SGML environment, developing the DTDs, the FOSIs, and the
necessary tools to get to (from the client's point of view) the same point?
How exactly *do* you estimate the "future savings" and measure this
agains the "up-front processes"? And how *is* this compared to to
alternative approaches with which a client might be familiar? What sort
of hard figures and justification is the client presented with?
