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:Fw: Ethical Question From:Fred Perry <perryf -at- NINA -dot- PAGESZ -dot- NET> Date:Tue, 5 Jan 1999 17:31:09 -0500
>Does this scenario sound familiar? You?re well within the project
lifecycle, in fact testing ? a major project milestone -- starts next week.
However, because of deadline pressures, unreasonable client expectations,
and the ITERATIVE ;-) nature of the project lifecycle coding will continue
right up to the minute the project is turned over to the testers. The
project?s sacrosanct PROJECT PLAN calls for the documentation to accompany
the system into testing. <snip> But what do you do when the project moves
into the POLITICAL ZONE. When all project discussions revolve around what
the project will BECOME, not what it IS? After a project evolves and
develops cracks and fissures this is a deadly serious issue. Jobs and
careers are on the line, and not just your own.
>What do you do when asked to write about how a system WILL EVENTUALLY
behave while ignoring what is actually does. Remember, the person asking you
(an engineer or manager) has their job, and possibly an entire team?s or
group?s, on the line.
It sounds entirely familiar to me, as I am living the nightmare now. Leonard
Porello's advice of "document, document, document" is a sound one, and is
also known as "CYA". However, what I am pushing for with my own company is
the idea of release notes--those little pages that, to my mind, explain the
differences between what you've documented and the actual product. Elna
Tynes is right in the description of hitting a moving target. The developers
I work with insist that the product is going to work exactly as they
describe it, and yet I've seen only a little movement towards those plans.
So, combining Porello's and Tynes's points of view is the creation of a
document to the standards of those who pay your salary, while at the same
time being true to your audience by maintaining accuracy with release notes.
It is a rather unstated goal among the developers that *eventually* I won't
have to create those release notes.
The flaw with this plan, as I am sure some will notice, is when the
discrepancies between vision and actuality are huge. Then you simply must
make your stand and refuse to let a document go from you that is not
truthful, again reminding whomever needs to be told about the legal and
ethical ramaifications of essentially lying to the users.
