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:Re: Estimating page count for SW user guide From:"Bayne, Sonia E B246" <Sonia -dot- Bayne -at- CIGNA -dot- COM> To:"'TECHWR-L -at- LISTS -dot- RAYCOMM -dot- COM'" <TECHWR-L -at- LISTS -dot- RAYCOMM -dot- COM> Date:Tue, 30 Nov 1999 10:54:20 -0500
Debbie wrote thusly:
> However, I don't find her (Joanne Hackos) method easy for me and am
> other ideas.
..Which brings back a painful memory and Cautionary Tale (narrative mode
I was Doc Team Leader, and a new manager was hired. He was from Marketing,
no background in TW or any other kind of W -- but a nice guy, willing to
learn. I bought him a copy of Joanne's famous book, and we worked through it
together to plan our major project: rewriting a complete doc set to support
a major new release of our company's software. We took a dozen books, large
and small, and redesigned the information and organization. We changed the
approach from menu-based (and highly criticized by our users) to task based,
complete with (imagine this!!) input from actual users. Oh, at the same time
we moved to FrameMaker, developed new style guides and templates, and
adopted RoboHelp for the online help that went with the system.
We then broke the writing task into topic chapters, and assigned our team of
7 writers in 3 states (from WA to MA) to specific guides/chapters. Each
writer then estimated the number of pages for each assigned chapter,
following Joanne's methodology. This allowed us to come up with a time
estimate for completing the project and an aggressive but realistic
deliverable date. It was a lot of hard and time-consuming work, but really
helped us to see what we were faced with and develop a good project plan.
So how did it turn out? Well, market realities intervened and the delivery
dates for beta and release were crunched. Instead of the 25 weeks we needed,
we had 17. It was truly the Project from Hell -- I worked more OT hours than
I knew I had in me. But we delivered, after a fashion. (Just don't ask about
editing and peer review.)
And why am I sharing this sorry saga ? (apologies for length...) Because no
matter how carefully you plan and estimate, or how reliable a source
(Joanne) you use for estimating, in the end it too often comes down to a
delivery date promised by a Senior VP to a roomful of users, with no regard
to the realities of what is involved in the development/delivery cycle. Hmm,
which makes me think of the discussion on the list about lack of skilled
management in Doc depts.
PostScriptum: Two years later the company went through a major re-org. I'm
not there any more (that's a Good Thing) -- neither is that new Doc manager,
or that Senior Exec! But the users still like the "new" documentation...
Sonia, now happy in her new job.
Sonia E. Bayne
sonia -dot- bayne -at- cigna -dot- com
"I've had a perfectly wonderful evening. But this wasn't it." Groucho Marx