Fw: Military Documentation Today

[Smokey Lynne L Bare <slbare -at- JUNO -dot- COM>]

I, too, have been watching the military thread as well....and so....
(plus I am trying to compile a list of us who have written for various
military projects).  If you have ever done any military project writing,
please contact me at the address below ONLY with your name, e-mail
address, what you did, and where you were based.  Thanks.....

Snip:
> From: Steve Davis <>
>
> I work at the Redstone Technical Test Center, writing and editing test
> documentation.  We have a very strict format that we must follow (TECOM
> PAM 73-1).  Not only are the font, margins, graphics, and everything
> else prescribed, but we only 45 days after the completion of the test
to
> publish the report.  I don't have "free reign" over anything.  Working
> in Huntsville, Al might keep me sheltered from the real world, but I
> have never felt out of place at a STC meeting.  I feel like a regular
> Tech Writer, what ever that is.
>
SNIP

I think Steve really has a true perspective of military writing for
today.
Over the years I have done bits and pieces (Wright-Pat - F16 pilot
manual)
for government writing.  Granted most of the older material has poor
usability issues, but it was a format that was consistent.  It taught
newer
writers how to work within a structured framework.

But today, the Gov. has moved on to embracing the new ISO 12207 standards
that are replacing all of the 498 MIL STDs.  It has moved from a
mainframe-based documentation (SGML) into the modern world of
client-server
doc-on-demand publishing.  Those environments can not handle all the
'extras' found in the old fashioned format, without the lengthy
conversion
process.  Minimalist writing is coming forward to replace the redundancy
found in the older MIL STDs.

This forced modernization has really opened doors for technical
communicators' roles to finally come to light, and their ability to
assist
educating their Gov. clients on how usability and modern standards
produce a
higher grade of material for the end user.

The base I am assigned to is primarily (for those of you unfamiliar with
the
mil. org.) a Sears catalogue ordering center (online) for military parts
and
supplies (my team members - please close your eyes to this descript).  I
have been tasked to develop online documentation standardization
guidelines
for producing manuals online, and the documentation that covers software
life cycle development and deployment (web and in-house server).  This
was
done through the intermingling of a methodology based on an ISO premise
and
the 12207 standards.

I've followed this military thread on our techwhirler listserv for
several
weeks now, and to both, from those who wrote that they used to do this
earlier in their careers (most x-military and probably my seniors), and
those just starting in this field.... I say that being a military
writer/technical information architect/editor is no different than when I
ran a tech pubs department for the IS division for a major banc
corporation.

You have a prescribed style guide, you gather information from SMEs or
other
related materials, you compose and publish it according to those
guidelines,
and you distribute it according to a determined mailing list.  The only
process difference is the style guide requirements.  As Steve mentioned
in
his e-mail, military writers normally do not feel out of place at ANY
type
of conference.  Writing and publishing issues are common to all
specificities of any workplace.  The general (pardon the pun) difference
is
that there is just a uniformed person who has brass buttons, who signs
off
on the projects when it is completed.

The only difference I noticed was that Gov. client needed some updated
information and education as to what is happening in the TC field, as
they
usually are not SMEs in this area.  More often than not, I have also
found
if you take the extra time to educate them as to why a TCs or TWs methods
are better, you do not have the problem of getting your project approved.

The only other difference I noticed was that they are not generally
oriented
to documentation process management.  This is where a TC comes in and
explains it is a process methodology vs a project methodology.  With the
new
ISO 12207 being accept by DOD, the field is wide open to those who have
written software life cycle documentation.....but most
importantly.....those
who take the time to educate their client.
>


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=