Re: FW: Documentation Management

[Sharon Burton <sharonburton -at- EMAIL -dot- MSN -dot- COM>]

I am in a similar position with a favorite client. They have completely
redesigned the product, renamed the parts, and totally changed the look and
feel. Updating the old manual means replacing every single procedure,
changing much of the conceptual stuff, recapturing all the screens and
adding information about the new features. They wanted this all done in 10
weeks. With 2 writers. Did I mention that they want to go beta on December
17th and still, at this moment, do not have a product that runs for 10
minutes? And that parts of it do not yet exist? And we are supposed to have
a frozen manual December 15th.

I created a project plan, an outline with estimated number of pages and
estimated hours to write/edit/capture screens/index for the user guide. It
estimated out at about 1200 hours, IF WE HAVE A STABLE GUI AND GENERAL
FUNCTIONALITY THE WEEK OF THE MEETING. All the players met and approved the
outline and estimates and agreed that this was a very aggressive schedule.
And promised us the stable GUI with the bulk of the functions in place that
week. The other 2 smaller manuals and the extensive help were not included
in that project plan. Help is impossible to plan at this point because the
product still doesn't run... But all are aware that it will take time to do
these things as well.

It is now 6 weeks later and we cannot make the deadlines. The other writer
and I started documenting the inability to meet the deadlines due to project
slipping several weeks ago on our invoices and weekly reports. And
suggesting that the client start figuring out what other options that want.
They seem to get the idea that because of the lack of product, it is
impossible to do what we all agreed needed to be done.

The moral of this story is that the planning done weeks ago has saved us.
Everyone knows the time that is involved and that as the project slips, so
will the docs. They have metrics and hours they can look at and see that
there are simply not enough hours left to meet these deadlines. Now it is on
them to tell us what they want to do. They need to make the decisions about
their product. But they have the hard numbers in front of them to make these
decisions with. Meanwhile the other writer and I are doing the fastest/best
we can but we know that when those dates come and go, nothing will be ready
and we can document why.

Took me years to figure out that JoAnn Hackos is right. We don't have time
to not plan. And working against a plan let's us all know what is being
delivered, when, and how much it will cost. It is hard and time consuming
but we had to take the time to do it so we would know what we will deliver
and everyone knows what to expect.

My doc plans. I think I'll keep them.

sharon

Sharon Burton-Hardin
President of the Inland Empire chapter of the STC
Anthrobytes Consulting
Home of RoboNEWS(tm), the unofficial RoboHELP newsletter
www.anthrobytes.com
Check out www.WinHelp.net!
See www.sharonburton.com!

-----Original Message-----
From: Lynn Perry <CLPerry -at- WALLDATA -dot- COM>
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU <TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU>
Date: Wednesday, 02 December, 1998 3:39 PM
Subject: FW: Documentation Management


>Keith
>
>When you accepted the contract, what was the schedule at that point? This
>may be the way to go about discussing the issue. I found myself in a
similar
>situation. I took a job that was scheduled for 6 weeks. It was putting
>together a 200-page book from input from eight different subject-matter
>experts (SMEs), each of whom had varying degrees of writing ability. They
>wanted this thing printed and bound. I told them that printing schedule for
>a book of 400 pages (which is what it had grown to by this point) was in
the
>neighborhood of 4 to 6 weeks. They assured me that the printing could be
>done in the time they wanted.
>
>It should have been a clue for me that no one else had even been
interviewed
>for this job. If my agency had been more aggressive in investigating the
>actual job, I certainly would not have taken it. I thought it would be good
>experience. Instead, I got a bit of the same kind of treatment you did. I
>worked 14 and 16 hours for the entire 6 weeks. No one reviewed the whole
>doc; I got only partial reviews of specific chapters. When the doc was
>shipped to a "beta" group about 4 weeks into the project, they dinged me
for
>doc quality, format, content, coherence, grammar, etc.
>
>It was an impossible job, and I just didn't have the experience to know it.
>If I had it to do over, I wouldn't take the job to begin with.
>
>On the other hand, I've had extremely tight deadlines and
busy/uncooperative
>SMEs. In some cases, I created content from what I could guess myself from
>running the product or researching  similar areas. Sometimes it has worked,
>sometimes it hasn't (by "worked," I mean: "they thought the doc was great
>and I was an invention on par with sliced bread;" by "not worked," I mean
>"they thought the doc was terrible and I was a talentless imposter).
>
>It's hard to say whether they could use your help (as the SME for doc) to
>rethink their schedules and project scope or whether they already have
their
>minds made up and are moving you out. In any case, my advice is to get help
>from managers or whoever else you can. Don't try to go it alone. If you
>can't get the help you need, it may work to inform your hiring manager (or
>whoever) that they may need someone else for the job. Personally, I've
found
>that not being able to complete a project is rarely one person's fault,
>especially the doc developer.
>
>Good luck.
>
>C. Lynn Perry
>clperry -at- walldata -dot- com
>Opinions expressed are mine alone
>Wall Data Incorporated, Seattle  WA
>Some days it doesn't pay to gnaw through the straps
>
>
>From ??? -at- ??? Sun Jan 00 00:00:00 0000==
>
>


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