Re: Cost effectiveness of switching tools WAS: Using Word's Hidden Text as a conditional....)

[Candace Bamber <cbamber -at- CASTEK -dot- COM>]

Hi -

Mike Huber wrote, regarding the cost of moving from Word to FrameMaker:

>I'm not saying it's not a good move (still have some research to go before
I make my >recommendation, even then, your mileage may vary) but there is a
definite down-side. >Moving from one software package to another always
carries costs. The question is >whether the costs of staying with Word are
higher than the costs of moving.

I've maintained a private database of "time it takes to do stuff" since my
first freelance writing job 13 years ago (very useful for estimating stuff,
but that's another issue). About 18 months ago, my then-team switched from
Word 6.0 to FrameMaker 5.1.1. My numbers indicate  that:

1.  Within 2 months we had leveled off at about a 35%-40% increase in
productivity (total production time per page) for a group of five people.
Frame paid for itself and made a profit for us in a hurry in this case.
2. This FrameMaker team beat the productivity on other Word teams I've
led/worked in by anywhere from 10% to 50% (NOTE: tool isn't the only
consideration; other factors had an influence as well).
3.  In no cases did a Word team come up with better productivity that this
FrameMaker team.  Data not scientific as I only have data for one
FrameMaker team.

Two reasons mainly -
1. Frame rarely crashed, and when it did, our "crash files" typically
contain everything we wrote except about the last sentence or so. Word
crashed all the time and unless we had the habit of saving every thirty
seconds, there was inevitable retyping. note: Word crashed all the time
because we were pushing it to it's limit in terms of document size - a
typical document that came out of our group was 30 - 60 Meg in size.
2. Production: in Frame you make a book and print it. You don't have any of
the floating footers, pagination, randomly moving graphics, etc. problems
that we, at least, had routinely with Word that meant that every time we
printed we had to manually review and adjust every single page in the
document. With Word, we had some docs that would take 2 days to print by
the time we sorted all the random production glitches.

This was not what I would call a simple implementation, either - the Frame
docs we were producing had 16 existing conditions with about another 40 to
come over the next three years. We had graphics in every format imaginable.
We had a development community that used Word and was not going to change.
We had a complex style sheet that exists for two different page sizes.

I believe there are three key things that have to be done to minimize
change-over cost (in addition to everything else that is required by your
unique situation):

1. PLAN, PLAN, PLAN
2. If your file storage is not perfectly clean and standardized for your
docs, design an information management system that works for you, maintain
an index of it, and stick to it. Frame's book building, and picture and
text referencing features are EXTREMELY efficient if you know exactly where
everything is and it's always named the same way and in the same place
relative to other files. (Particularly important if you are maintaining
multiple variations of the same book and if you are allowing development
staff to look at stuff on-line using FrameReader)
3. Make sure the style names on your Frame template and your Word template
match. (This makes it possible for writing to continue even if no-one knows
the tool  - Type, apply the appropriate and well-known style from the list.
And consistent style name really helps expedite moving documents from Word
to FrameMaker and back)

One thing we didn't do right - it would likely have been to our advantage
to send at least one person to a FrameMaker training course. (Whatever
would I have done without the folks on the Framers list?)

While I recognize that FrameMaker may not be what everyone needs, for us it
was a cost-effective solution to a problem that was starting to cost us
serious time and money (not to mention the frustration factor!).

I can provide detailed hard data if you're interested in reviewing it,
Mike.

Cheers

Candace
cbamber -at- castek -dot- com
***************************************************************************
*********************************************
Candace Bamber

now thankfully at:            "Whatever you can do or dream,
Castek Software Factory    Begin it.
Toronto, ON, Canada                 Boldness has  genius,  magic and power in
it."
416-777-2550 X 331                      --- Goethe
***************************************************************************
*********************************************

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html