Re: Why Frame not Word?

[Bev Clark <bclark -at- GRACE -dot- RT -dot- CS -dot- BOEING -dot- COM>]

A very long post follows.

One thing to remember about managers is that they're looking for business
reasons for their decisions: time, money, productivity, things like that.
You need to give them some *business* reasons for why FrameMaker is the
better solution for your needs.

A case study from my own experience: Several years ago I had a similar
problem in my organization. We were in a Unix environment, from technical
specialists to managers and secretaries. My group was using publishing
software that integrated text and graphics and some other capabilities to
produce a variety of material that ranged from one-page, minimally
formatted information bulletins to a long, complex document that had a
different author and production cycle for each of 27 sections and was
updated annually.

Management had brought in "office productivity software" that appeared to
perform some of the same functions as the publishing software; it had a
graphics tool, a database tool, and a spreadsheet tool as well as word
processing capability. The software was neither intended nor adequate for
dedicated publishing; even the vendor's sales rep admitted that.
Nevertheless, we came under pressure to use the office software for
producing our documents. Senior managers thought we could save money by
eliminating what looked like duplicate software and save time by having
everyone use the same software, eliminating compatibility problems.

What I did -- which worked:

1.  I listed all the types of documents we produced.

2.  I described the fundamental characteristics of each document -- things
like structure, length, number of writers, source and complexity of
graphics, frequency of revision, and review process.

3.  From this list of document characteristics, I came up with a list of
the minimum capabilities we needed in *any* software we used to produce the
documents, given that we had to use one software package for everything. I
also identified which of these were most critical.

4.  I put together a matrix comparing how well our current software and the
office software did on each of the minimum capabilities. Because no one in
my group was an experienced user of the office software, I worked with our
"power user" to document how well the new software met our requirements.
Our graphic artist, who produced most of our documents, did the same thing
for the publishing software.

5.  I put together a test: a fairly typical technical report, with a
typical turnaround time, and had the office software power user and the
graphic artist track how long it took to produce the document in our
standard format, using the office software and the publishing software,
respectively. (The format and graphics in the report were within the limits
of what the trainer was used to doing for herself, so the graphic artist's
additional skill in those areas wasn't a significant factor.) I also asked
them to note problems they encountered and what they did about them.
    The result was that I was able to demonstrate that the office software
was inadequate for our needs. It took 2.5 times as long to complete a
typical technical report, one of the simpler documents we produced, using
the office software, and the workarounds the power user had used for some
of the problems she encountered were visible in the final quality. She also
couldn't meet the turnaround time.


Bev

Bev Clark
bclark -at- grace -dot- rt -dot- cs -dot- boeing -dot- com
Boeing Computer Services Research and Technology
________________________________________________________
My opinions are my own, not those of The Boeing Company.
________________________________________________________