Pages Per Day

[Jim Barrow]

The software project that our tech pubs team has been working on has suffered from frequent delays and setbacks. As writers, we knew that we would have a tight deadline in regards to generating the end user documentation. During yesterday’s “kick off” meeting we discovered just how tight this deadline is.

A little background information to build the suspense first…

This software application is huge – a basic ERP system with four separate modules. There are 50-75 use cases per module. In my estimation there’s going to be ~500 pages of documentation.

Back to yesterday’s meeting…

The project manager – and one upper-manager – gave us (are you ready for this?) four days to complete the end-user guide. The amusing part was that they scheduled five days to decide on a table of contents, and two weeks for review.

Four days.

I’m in the process of composing my response to this timeline but, short of responding with “dear project manager, since you were obviously under massive amounts of narcotics during yesterday’s meeting,” I’d like to come up with something that’s a little more like metrics and hard facts.

A long time ago, in a galaxy far, far away, I seem to recall that the tech writing standard for producing documentation that is ready for publication is 2-3 pages per day. Seems a little low, but that’s what I recall. Does this sound correct to you?

- Jim

[Bill Swallow]

It really depends on a lot of factors, but with 50-75 use cases per
module and 4 modules to document, I can't see how anyone could
possibly think it possible to document 50-75 use cases in a single
day.

My advice is to scope 4 days of work and also scope the job as if time
hadn't been negotiated yet. Then go in with "this is what you can
expect in 4 days" (my guess is that it will be a lackluster, thin
piece of useless info) and "this is what it'll take to document the
entire application from these use cases". Then let the negotiations
begin.

This software application is huge – a basic ERP system with four separate modules. There are 50-75 use cases per module. In my estimation there's going to be ~500 pages of documentation.
The project manager – and one upper-manager – gave us (are you ready for this?) four days to complete the end-user guide. The amusing part was that they scheduled five days to decide on a table of contents, and two weeks for review.

[Gordon McLean]

Does it matter?

Give them an upper and lower bound (based on 2 days and... 4?) ... It'll
still be way more than the 4 days you've been given.

I'd also give them the list of what you COULD achieve in that time, so they
can make a judgement call between the two (and possibly a third option
halfway between the ideal and the impossible?)

Good luck.

Gordon

-----Original Message-----
From: techwr-l-bounces+gordon.mclean=***@lists.techwr-l.com
[mailto:techwr-l-bounces+gordon.mclean=***@lists.techwr-l.c
om] On Behalf Of Jim Barrow
Sent: 27 March 2008 14:10
To: techwr-***@lists.techwr-l.com
Subject: Pages Per Day

The software project that our tech pubs team has been working on has
suffered from frequent delays and setbacks. As writers, we knew that we
would have a tight deadline in regards to generating the end user
documentation. During yesterday's "kick off" meeting we discovered just how
tight this deadline is.

A little background information to build the suspense first.

This software application is huge - a basic ERP system with four separate
modules. There are 50-75 use cases per module. In my estimation there's
going to be ~500 pages of documentation.

Back to yesterday's meeting.

The project manager - and one upper-manager - gave us (are you ready for
this?) four days to complete the end-user guide. The amusing part was that
they scheduled five days to decide on a table of contents, and two weeks for
review.

Four days.

I'm in the process of composing my response to this timeline but, short of
responding with "dear project manager, since you were obviously under
massive amounts of narcotics during yesterday's meeting," I'd like to come
up with something that's a little more like metrics and hard facts.

A long time ago, in a galaxy far, far away, I seem to recall that the tech
writing standard for producing documentation that is ready for publication
is 2-3 pages per day. Seems a little low, but that's what I recall. Does
this sound correct to you?

- Jim

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more.
http://www.DocToHelp.com/TechwrlList

True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com

---
You are currently subscribed to TECHWR-L as
***@grahamtechnology.com.

To unsubscribe send a blank email to
techwr-l-***@lists.techwr-l.com
or visit
http://lists.techwr-l.com/mailman/options/techwr-l/gordon.mclean%40grahamtec
hnology.com


To subscribe, send a blank email to techwr-l-***@lists.techwr-l.com

Send administrative questions to ***@techwr-l.com. Visit
http://www.techwr-l.com/ for more resources and info.



____________________________________________________________________________________________________
This email (and any attachments) is private and confidential, and is intended solely for the
addressee. If you have received this communication in error please remove it and inform us via
telephone or email. Although we take all possible steps to ensure mail and attachments
are free from malicious content, malware and viruses, we cannot accept any responsibility
whatsoever for any changes to content outwith our administrative bounds. The views represented
within this mail are solely the view of the author and do not reflect the views of the organisation
as a whole.
____________________________________________________________________________________________________
Graham Technology plc
Registered in Scotland company no. SC143434
Registered Office India of Inchinnan, Renfrewshire, Scotland PA4 9LH

http://www.grahamtechnology.com
____________________________________________________________________________________________________

[j***@garisons.com]

The project manager – and one upper-manager – gave us (are you ready
for this?) four days to complete the end-user guide. The amusing part was
that they scheduled five days to decide on a table of contents, and two
weeks for review.

I'd go with the narcotics line as a lead off ... then tell them that you
can do it in 20 seconds and hand them a sheet with the letters of the
alphabet, numerals 0-9, and punctuation marks with a note that says
"Duplicate and arrange as required."

Seriously, I recall a metric of a page a day for research, writing,
technical reviewing, and prepping for pubication. A lot depends on how
thorough the planning and specification process is. If it's done well and
the writers are active participants, it can speed up the writing quite a
bit. A lot depends on the discipline of the organization. If developers
are constantly squeezing in new things without warning, or making changes
without a change management system in place, it will add to the time
required.

How much do they care about good documentation and support? What will the
tech support people use to answer the questions that will undoubtedly
arise when such a poorly documented application hits the streets? Do they
care about astronomical support costs? How many do they expect to sell and
how many people will use it? All of these factor into the planning.

I don't suppose you could ask if they made a mistake and meant four months
or perhaps quarters - to do the job instead of days?

My 2¢,

John G

[Julie Stickler]

I've been using the dependency calculator on the ComTech Web site ever
since someone posting it to one of my mailing lists.

http://www.comtech-serv.com/dependency_calculator.htm

I've been keeping track of my own productivity for a couple of years
now, and so far my personal numbers match the estimator pretty well.
My previous gig ran 3 - 5 hours per page, depending on the project.
My current gig (which is a *tad* less structured and has no
specifications to help me get up to speed) is taking me quite a bit
longer. I haven't finished my current project yet, but the estimates
from the dependency calculator are 8 - 9 hours per page, which may
explain why this project seems to be taking forever. *groans*

At five hours per page, tell them that you (lone writer?) can write
them six and a half pages of documentation in four days. If you've
got a team, do the math for the team. Then, as Bill said, let the
negotiations begin.

BTW, how long did they spend coding this monster? I'm sure it wasn't
four days... Sounds like they brought the writers in a little late in
the process. I always want to say (but usually end up just muttering
inside my head) "Lack of planning on your part does not constitute an
emergency on my part...."

[Suzette Leeming]

Somewhere I heard the expression "documentation can be 1) good, 2) fast, and
3) cheap. Pick two. If they want it that fast, and still want it to be good,
it isn't going to be cheap and will probably involved hiring a crew of
contractors to help out. If they don't want to do that, then it will be fast
and cheap, in which case it isn't going to be good.

Thanks for the link to the dependency calculator, Julie. It may come in
handy when I need to justify my own time :-)

I use Help & Manual, and tend to complete 4-5 topics per day. Of course,
that depends on the complexity of the topic though. Some topics may take a
couple of days to complete, while others can be finished in 15 minutes. I'd
like to be able to figure out an average.

Speaking of complexity, our application is modular and consists of
approximately 10+ modules. Some modules have user manuals that are 700 - 800
pages long. I am a lone technical writer who has only recently convinced
them that this is NOT a part time job. I tried to convince them to hire
another techwriter, so that we would be able to build up our knowledgebase,
as well as create training manuals and guides. I should have kept my mouth
shut though, because they love the idea of training materials, and have
added that to my list of tasks.

I responded by booking vacation (starting next week).

There are a lot of pointy-hair bosses out there.

Suzette Leeming

Post by Julie Stickler
I've been using the dependency calculator on the ComTech Web site ever
since someone posting it to one of my mailing lists.
http://www.comtech-serv.com/dependency_calculator.htm
I've been keeping track of my own productivity for a couple of years
now, and so far my personal numbers match the estimator pretty well.
My previous gig ran 3 - 5 hours per page, depending on the project.
My current gig (which is a *tad* less structured and has no
specifications to help me get up to speed) is taking me quite a bit
longer. I haven't finished my current project yet, but the estimates
from the dependency calculator are 8 - 9 hours per page, which may
explain why this project seems to be taking forever. *groans*
At five hours per page, tell them that you (lone writer?) can write
them six and a half pages of documentation in four days. If you've
got a team, do the math for the team. Then, as Bill said, let the
negotiations begin.
BTW, how long did they spend coding this monster? I'm sure it wasn't
four days... Sounds like they brought the writers in a little late in
the process. I always want to say (but usually end up just muttering
inside my head) "Lack of planning on your part does not constitute an
emergency on my part...."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more.
http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
To unsubscribe send a blank email to
or visit
http://lists.techwr-l.com/mailman/options/techwr-l/suzette.leeming%40gmail.com
http://www.techwr-l.com/ for more resources and info.

[Melissa Nelson]

I think Tina the Techwriter said it best when her boss decided he would pay her based on the number of pages she produces. She replied "Fine, I will give a high volume of low quality work!" I have that particular strip hanging in my cube! :)

Melissa

[Gene Kim-Eng]

The theoretical "two pages per day" figure covers
the entire publication process, so it includes the
effort required for planning, reviews, updates and
final release.

Gene Kim-Eng

[Peter Neilson]

Was there a documentation plan?

In general, the successful projects with which I have been involved have
had a docplan. When the docplan was omitted, by ignorance, by
happenstance or by design, through my fault or through others', success
has been lacking as well.

"The docs will be done in four days," is not a docplan. "I think we all
know what's required," is also not a docplan.

In a well-written world, docplans are the first part of the writing, are
completed and reviewed around the same time that the design specs are
being written (oh, those are being omitted, too?) and actually involve
the writing team. They are occasionally revised, as necessary.

If the world operates on a lower rung, a smaller budget, or a more agile
(or fragile) model, perhaps the writing team are handed a docplan when
they are brought on board, four to six weeks before FCS.

Sometimes, though, the project's ladder was designed by Dante, and the
rungs are even further down. The company has no name, but the writer is
Tina.

[Gordon McLean]

I'm saving this one, cheers John, made my day!!

-----Original Message-----
"... tell them that you can do it in 20 seconds and hand them a sheet with
the letters of the alphabet, numerals 0-9, and punctuation marks with a note
that says 'Duplicate and arrange as required.' "


____________________________________________________________________________________________________
This email (and any attachments) is private and confidential, and is intended solely for the
addressee. If you have received this communication in error please remove it and inform us via
telephone or email. Although we take all possible steps to ensure mail and attachments
are free from malicious content, malware and viruses, we cannot accept any responsibility
whatsoever for any changes to content outwith our administrative bounds. The views represented
within this mail are solely the view of the author and do not reflect the views of the organisation
as a whole.
____________________________________________________________________________________________________
Graham Technology plc
Registered in Scotland company no. SC143434
Registered Office India of Inchinnan, Renfrewshire, Scotland PA4 9LH

http://www.grahamtechnology.com
____________________________________________________________________________________________________

[Will Husa]

Jim,

When I bid on a project, I usually use a formula that includes $3.15 hours per page. That may help your question.

As to your unrealistic expectations situation, a PM once gave me FOUR HOURS to write a "user guide" to meet a delivery deadline. The next day, the VP complained to the PM that "This isn't a user manual. Where's my user manual?"

Be seeing you,

Will

====================================
Will Husa

Technical Writer of User Friendly Procedure Manuals and HTML Help <
Increasing Profits through Clear Communication <

Phone: [phone]
Fax: [phone]
www.4techwriter.com
====================================
The software project that our tech pubs team has been working on has suffered
from frequent delays and setbacks. As writers, we knew that we would have a
tight deadline in regards to generating the end user documentation. During
yesterday’s “kick off” meeting we discovered just how tight this deadline is.

A little background information to build the suspense first…

This software application is huge – a basic ERP system with four separate
modules. There are 50-75 use cases per module. In my estimation there’s going
to be ~500 pages of documentation.

Back to yesterday’s meeting…

The project manager – and one upper-manager – gave us (are you ready for this?)
four days to complete the end-user guide. The amusing part was that they
scheduled five days to decide on a table of contents, and two weeks for review.

Four days.

I’m in the process of composing my response to this timeline but, short of
responding with “dear project manager, since you were obviously under massive
amounts of narcotics during yesterday’s meeting,” I’d like to come up with
something that’s a little more like metrics and hard facts.

A long time ago, in a galaxy far, far away, I seem to recall that the tech
writing standard for producing documentation that is ready for publication is
2-3 pages per day. Seems a little low, but that’s what I recall. Does this
sound correct to you?

- Jim

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more.
http://www.DocToHelp.com/TechwrlList

True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com

---
You are currently subscribed to TECHWR-L as ***@4techwriter.com.

To unsubscribe send a blank email to
techwr-l-***@lists.techwr-l.com
or visit
http://lists.techwr-l.com/mailman/options/techwr-l/will.husa%404techwriter.com


To subscribe, send a blank email to techwr-l-***@lists.techwr-l.com

Send administrative questions to ***@techwr-l.com. Visit
http://www.techwr-l.com/ for more resources and info.



--

[Julie Stickler]

Post by Gene Kim-Eng
The theoretical "two pages per day" figure covers
the entire publication process, so it includes the
effort required for planning, reviews, updates and
final release.

Gene is absolutely correct.

Jim said that at the "kick off" meeting they were told that they had
four days to crank out the documentation. Which is why I asked how
long they were planning for the coding phase? In my mind, the writer
should have access to specifications and test builds, which should let
you get a running start on writing your documentation long before the
developers get to "code complete." Jim's already got enough
information to come up with a page count estimate, so he is at least
into the planning phase. Which just makes me wonder how far into the
project they are, and what exactly they were "kicking off" at this
meeting?

Waiting until the end of the cycle to bring in documentation is a pet
peeve of mine. Several years ago, two days before product ship date,
a product manager suddenly realized that we also needed an upgrade
guide. He asked me if two days was enough time to write one? I was
new on the product, but it didn't take me long to find that our
upgrade guides were usually about 200 pages long, and to figure out
that we actually had three different upgrade paths, which meant not
one guide, but three. We didn't have enough upgrading customers to
hold up the release, but his "little two day project" ended up being
several weeks of work.

I hate it when people think that documentation will somehow just
magically appear. Code takes time to write and test. And you need
time to plan, research, write, and test documentation too.

[Gene Kim-Eng]

During my consulting days I was once approached by
a company that was in about the same place that Jim's
seems to be. They wanted a big user manual (not quite
the 500-page tome that Jim's being tasked with, but
close) in a two-week period, and asked if I could do it
and if so, how much it would cost. I told them yes, it
could be done, and that my fixed-rate fee would be
$500,000. I explained that it would have to be that
much to cover the 50 writer-subcontractors I would have
to bring in for a two-week familiarization period, during
which all the developers would need to be tasked 100%
with briefing the 50 writers, followed by the two-week
documentation period.

I finally ended up delivering a 25-page quick-start
guide, which was rather well-received by the customer.
The next time the company called me, it was for a
contract that began during the initial product feasibility
study.

Gene Kim-Eng


----- Original Message -----

Post by Julie Stickler
Waiting until the end of the cycle to bring in documentation
is a pet peeve of mine.

[Ned Bedinger]

The project manager – and one-upper manager – gave us (are
you ready for this?) four days to complete the end-user guide.
The amusing part was that they scheduled five days to decide
on a table of contents, and two weeks for review.
Four days.

Run, don't walk to the next meeting--it is going to be memorable and I
think you'll enjoy it a lot. The project manager (PM, the one with the
aggressive schedule) will be there, nervously eyeing those other
managers. Don't stare, but yes, those are they eyes of prayer. PM is
praying that the other managers will continue to provide their
fellowship and support even after they've heard what is going to be said
in the meeting.

This happens because you stayed loose and uncommitted to the desperate
acts of reasoning that everyone expects you to present. You do know that
the PM locker room was buzzing with $500 bets just before the meeting?
The pool is several thousand ducats!

Oh! to be a fly on the wall in this meeting.

Fortunately for your team of writers, you called PM late yesterday
afternoon and left a voice mail saying that you'd like time in the next
meeting for PM to give a brief, specific explanation of how deadlines
are calculated, with the current one as an example. For all intents and
purposes, you said "No, this time let's see *your* numbers!"

And this is how to whip them fair and square, with business questions
and business math. Got MBA? You KNOW it isn't your numbers that are
hinky.

Oh well, maybe PM will be better to work for after this experience.

Congratulations Jim!

I’m in the process of composing my response to this timeline but,
short of responding with “dear project manager, since you were
obviously under massive amounts of narcotics during yesterday’s
meeting,” I’d like to come up with something that’s a little more
like metrics and hard facts.

I thought you said the PM was on uppers? Anyway, I hope the pep talk
helps you digest some of the baloney that PM is slicing for your team.

Ned Bedinger
***@edwordsmith.com

[Sarah L Blake]

500 pages of documentation in four days?

Assuming an eight-hour day, that's, uh, fifteen and a half pages an
hour.

A quick look at my own documentation suggests about 400 words a page...

...you do type at 100wpm, right?

Sarah Blake
Technical Author

exony

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

[Peter Neilson]

No, no, I'm sure that they have figured out that it's feasible, because
little is required other than "wordsmithing" the existing e-mail and
marketing memos. Most of the stuff is in good shape already, but some of
it is in the wrong font. (There certainly won't be any proprietary
material to be removed, lapses in logic, or hopeless non-sequiturs.)
Tech writers used to be called secretaries, right?

Post by Sarah L Blake
500 pages of documentation in four days?
Assuming an eight-hour day, that's, uh, fifteen and a half pages an
hour.
A quick look at my own documentation suggests about 400 words a page...
...you do type at 100wpm, right?

[Chris Borokowski]

It may be high, depending on how it is measured. Some projects require
a pages per day estimation that includes research. Some products are
complex enough that one page a day is an excellent rate.

Post by Jim Barrow
A long time ago, in a galaxy far, far away, I seem to recall that the
tech writing standard for producing documentation that is ready for
publication is 2-3 pages per day. Seems a little low, but that?s
what I recall. Does this sound correct to you?

http://technical-writing.dionysius.com/
technical writing | consulting | development


____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ