One of the most difficult things to do, especially when you are getting started as a technical writer, is to size, or estimate, a writing job. And that is exactly what management and clients want you to do right up front: tell them how long it will take you to create the documentation from start to finish and how much it will cost.
This post was prepared by guest blogger, Deb Lockwood, a lead technical writer for CSG Systems, Inc. While Deb’s approach to sizing or estimating writing projects is oriented toward technical writing and editing (e.g., software and hardware user guides and online help topics), any writer will benefit from Deb’s thought process on how to size a writing project.
It can be difficult to know how to assess a project size. Some folks use formulas that they’ve seen on Web sites or read in books, some ask other writers, and some resort to wild guesses. In this post I suggest a more reliable and realistic method: ask yourself!
If you search the Internet you may run into some formulas that purport to hold the key to the “how long and how much” questions. A technical writing expert might recommend that you estimate the project size as time per page (e.g., an hour of writing time per page). Although that formula might prove helpful to an experienced writer, that method assumes that you know up front approximately how many pages you will end up with, which is not very likely unless you are editing an existing document.
After many years of searching for and being frustrated by these types of formulas I have discovered that the best way to size a writing project is for writers to gather their own metrics for themselves. My reasoning is simple. The length of time it takes you to do something might be a totally different number than how long it takes for the next person to do that same thing. Also, that other person might include other factors in his or her calculations (e.g., editing time) and you may not do the same.
I’ve found that the amount of time it takes me to write, edit, and finalize a writing project varies widely depending on the following factors:
- Will I be using a template? If I use a template I’ll have fewer decisions to make about the document’s layout. Fewer decisions equals shorter timeframes.
- Will I be writing using style standards? If I am writing the information for my employer according to our company’s set standards, things will probably go quicker for me because I’ll have fewer verbiage decisions to make.
- Do I need to scrounge for information? Am I going to need to scrounge around for source information, or are there designs or other types of information that I can use to learn about the topic (e.g., existing software application system designs that can be used for new software applications)? If there is sufficient source information, it usually takes me less time to ramp up and write it up. Scrounging can take a lot longer.
- Will I be producing user guides (longer) or help topics (shorter)? I find it quicker to write and arrange help topics than to create a guide from scratch. Help topics are smaller chunks of information that are based on a single topic, like “Logging on,” “Adding addresses,” or “Setting security.”
- Do I need to deliver the project whole or in parts? Sometimes projects can be delivered in parts or phases. Does management or the client expect me to create the entire thing all at one time, or can I create a part of it now (phase 1) and additional parts (phases 2-3) at a later time?
- Do I already know the content development tool? If you are expected to create the document using Microsoft Word, do you already know how to use that tool? Or if they are online help topics, do you know MadCap Flare or whatever tool in which you will author the content?
- If there will be graphics in the deliverables, do I produce those, and do I know the tools? Am I expected to include graphics or screen shots? If I am to include screen shots, things will probably go fairly quickly. If I have to create, purchase, or otherwise find graphics, the project is going to take me a long time. I may even have to contract out that work to a graphic artist.
- What is the type of content? Is the information I’m creating concrete (such as processes or procedures), or is it about or concepts? Conceptual language normally takes me longer to create. Procedures go pretty quickly.
- Am I familiar with the overarching topic that I am documenting? If I have already been exposed to the topic, I will have less ramp-up time, which translates to less writing time.
- Did I write the original draft, or am I editing someone else’s work? If it is someone else’s, it will probably take me longer than writing something from scratch myself because the content will be brand new to me. Of course, the amount of time it takes me will also depend on who the other writer is, his or her skill level, and his or her comfort with the topic.
Remember that things can and do happen. For example, you may have computer problems, files might get corrupted, or family issues might arise. Make sure to account for unanticipated events. To do so, add an additional 10% to your total estimated project time.
By gathering metrics about yourself and your methods for creating writing projects, you can more effectively size your writing projects. Using your own numbers will ensure that you end up with a realistic picture of what it will take to produce the final deliverable.
About the Author
Deb Lockwood is a lead technical writer with CSG Systems, Inc. (www.csgsystems.com) and an Associate Fellow with the Society for Technical Communications (STC) (www.stc.org). Besides writing and volunteering her time to the STC, she runs a job search networking group called Ready, Set, Work at her church in Westminster, Colorado. To support that networking group she authors that group’s blog (http://readysetwork.wordpress.com/). Deb’s LinkedIn profile is available at http://www.linkedin.com/in/deblockwood.