Replies to This Discussion

Permalink Reply by Mark Baker on February 16, 2012 at 10:25pm

Hi Tom,

It definitely varies. There are averages that may provide rough guidance over a sufficiently large project or a number of projects, but for a single project those averages may be useless. Indeed, an organization's internal metrics based on past projects in their own organization are often a better guide than industry-wide numbers, which are averages of dissimilar projects in dissimilar organizations.

The biggest part of a writing project is not the writing, but the research. Some key factors:

- Are you being asked to edit material provided by others or to write the material from scratch?

- Are you being asked to write new docs or to update an existing doc set?

- If there is an existing doc set, is it in good shape or are the outstanding deficits that should be made good, in addition to adding new material?

- Are there detailed specifications available for the project? If not, how accessible are the developers and product managers, and how much time can they devote to answering your questions?

- Is there a working version of the product available for you to use? If not, when will one be available?

- How much do you know about the task domain of the product's users? In other words, how much do you know about the people who will be using the product and the things they will be doing with it? Have you done those tasks yourself? Are you an expert in that area? If not, do you have access to people who are doing these tasks (which can include indirect access, such as reading Internet forums where they hang out)? Are the developers or designers working with personas (written descriptions of typical users)? If they are an agile shop, are they working with user stories, and if so, do you have access to them?

- Are there similar products on the market whose documentation you can examine? If so, have you ask your employer if the competitor's documentation is a similar in scope and detail to what they want for their own product?

- Do you know enough about the development process that you can ask reasonable questions of the developers and understand their answers?

If you have done any writing before, then you probably have a pretty good idea of how long it takes you to write something once you have all the information you need. The biggest variable is how long it will take you to get that information, and that can vary widely depending on how you answered the questions above.

Hope this helps.

• ▶ Reply

Permalink Reply by Thomas Mauser on February 17, 2012 at 8:14pm

Hello Mark,

Thank you very much for replying to my inquiry and for providing me with your key factors that impact estimate for writing projects - it's greatly appreciated!!

Best regards,

Tom Mauser

• ▶ Reply

Permalink Reply by Daniel Archer on February 21, 2012 at 2:31pm

The biggest variable is how long it will take you to get that information, and that can vary widely depending on how you answered the questions above.

Exactly. For me, it's all about the UI - how fast will it be ready and how many half-baked iterations of the document are going to be required by the project schedule / client before the UI is really ready? I spend 25-50% of my time making incremental updates. If I could start the day the last bit of code was done and have all my business rules, use cases, and user stories firmly in hand, I'd write/create much faster.

• ▶ Reply

Permalink Reply by Jenny Watson on February 17, 2012 at 1:09pm

Hi Tom

I've found this a useful resource as a starting point for estimating projects - http://www.writingassist.com/pdfs/WAI_EstimatingWritingProjects_V4_...

It was something I stumbled across a few years ago when I was looking for help estimating a project.

Jenny

• ▶ Reply

Permalink Reply by Thomas Mauser on February 17, 2012 at 8:15pm

Hello Jenny,

Thank you very much for your reply and for providing me with the link to a writing project estimates resource!

Best regards,

Tom Mauser

• ▶ Reply

Permalink Reply by Melanie Blank on February 21, 2012 at 12:09pm

Jenny - this is helpful, too - thanks,

Melanie

• ▶ Reply

Permalink Reply by Melanie Blank on February 21, 2012 at 12:07pm

Tom - this is a question I have struggled with, and obviously I'm not alone.  Mark brings up some excellent points - I always benefit from his comments.  I'm also thinking of online help projects, where the "per page" unit doesn't apply - except for PDFs.  Even if you think of individual topics in a Madcap Flare project, which is my frame of reference, it it so hard to generalize and come up with a "per topic" no. of hours.  I think it helps to keep close track of your timing on all projects to guide you in coming up with reasonable estimates for the projects that follow. 

Melanie Blank, Rochester NY area, USA

• ▶ Reply

Permalink Reply by Julio Vazquez on February 28, 2012 at 1:30pm

There are definitely many variable, Tom and a lot depends on the type of information you're writing. Help information that is just detailing values for options in a UI doesn't take as much time as writing how to accomplish a task with the UI. Task information, in general, takes longer to write than reference information and conceptual information falls somewhere in between. As Mark said, the research takes a bunch of time and then there's the wait time; time you need to assemble the information from the various sources (of course they won't be ready when you're ready to write). Bottom line is that you probably wind up with averages based on experience and when you use them to predict the actual writing time you'll probably be anywhere from 15 to 25% off (usually on the low side). And they say Technical Writing isn't stressful. LOL.

If I were to use a rule-of-thumb, I'd peg a moderate sized task topic at around 4 hours per task, a reference topic at about 1 hour and conceptual topics at about 2.5 hours. The trick is identifying how many of each type you'll need. You can only do that by analyzing the product uses and distilling that into the tasks so you can identify the other topics you'll need.

• ▶ Reply

Permalink Reply by Melanie Blank on February 28, 2012 at 3:07pm

Thanks, Julio - helpful. :)

• ▶ Reply

Permalink Reply by Milan Davidović on February 29, 2012 at 8:57am

When you eventually do provide your estimate, it may be helpful to make explicit any key assumptions (i.e. important items that you can't measure directly) on which you've based it.

• ▶ Reply

Permalink Reply by Steve Schwarzman on February 29, 2012 at 9:54pm

I have a chapter on estimating projects in my book. It's chapter 5, "Estimating, tracking, and managing tech writing projects," in Technical Writing Management: A Practical Guide.

My main point there is that instead of using industry standards, which may or may not have much to do with your industry and your organization, you can quickly build a self-refining estimating model based on your actual experience in past projects that you have done.

• ▶ Reply