Estimating your writing efforts and deadlines is difficult, but essential.
Can you reliably estimate the time you need to write documentation? And the date when you can deliver? It often seems a daunting task because it depends on many external factors:
- The quality of specifications and designs.
- The availability of the finished product.
- The accessibility of subject-matter experts.
- The punctuality and diligence of reviewers.
It also seems futile to spend time estimating efforts when you know you don’t have enough time anyway. But even though it’s difficult and takes time, I recommend that you do it.
Why estimate?
If you don’t do it, someone else will make assumptions about your schedule. Even if you’re just left with the ever decreasing time between delayed development and scheduled shipment.
Estimating makes documentation accountable, in both senses of the word:
- You can explain the time you will spend on documentation. So it allows you to plan and budget the time. Share the estimates with your manager, and you can also share responsibility for the efforts.
- You can also be held accountable for the time you have spent. With estimates, you only will have to justify the specific difference that you ran over the plan. That’s much better than arguing about the complete time which may “seem kind of long” to your manager, though you know “that’s just how long documentation takes”…
Estimating makes documentation more transparent, in other words. It gives you and other stakeholders specific numbers to talk about ahead of time. It gives everybody more control over the documentation process.
For example, I once faced the complaint from product managers that documentation held everything up, that we could ship sooner, if only the tech writer got his act together. By introducing estimates and refining the reporting, I was able to show that it was specifically the reviewers which held up the process. Everybody took the estimated time, more or less, but reviewers delayed their tasks unduly. In fact, one late reviewer was a product manager who had voiced the complaint…
What to estimate?
You get what you measure and estimate. Or in the words of Tom DeMarco: “You can’t control what you can’t measure.”
If you estimate number of pages per day, you’ll get reams of paper. But that doesn’t guarantee that the documentation is useful and/or accurate.
If you count the number of features, options and buttons and base your estimate on that, you’ll get a thorough description of the user interface. And a customer who says, “Don’t tell me how it works, tell me how to use it.”
Apply task-oriented writing and estimate topics, instead:
- Look at the specifications and designs to understand what’s being developed or produced from a user’s point of view.
- Distill or translate what you find:
- Identify modular concepts that users will need to know. A microwave convection combination oven can use descriptions of both concepts with their principles and different use cases.
- Sketch out user workflows to set up and operate the product and break them down into individual procedures. That oven’s manual will probably have procedures to set it up, to thaw frozen food, to heat food (using the microwave), to bake stuff (using the convection), and to clean it.
A high-level view of the topics and their complexity allows you to make a rough estimate how long you’ll need to create useful topic-based documentation.
How to estimate?
Estimate efficiently. I once estimated a one-month project so well, I was off by two hours in the end. The problem was that it took me two days to crunch all the numbers… I can’t recommend that.
So don’t try to be 100% accurate in your estimate, if it takes you a long time to do it. Here are a few ideas to spend less time on estimates:
- Look at past efforts: Most likely, you’ll do some reporting anyway. Use this as the basis for future estimates. Maybe you’ll find an average time you take to write a concept topic. And one time period for easy and short procedures and another for more complex ones.
- Refine your estimates and average sizes over time: No need to get it perfectly right the first time, especially, if you start estimations on your own account. Try to run the numbers beneath the radar before you come forth with them.
- Trust the law of averages: What extra time you need for one topic, you’ll probably save on another.
- Trust your experience: After a while, you won’t need to sketch out individual topics. You’ll be able to take an adequate measure from looking through the spec or design.
Further reading
To learn more, check out:
- Donald LeVie’s Intercom article “Documentation Metrics”, available via EServer
- Steven Jong’s STC paper “Measuring Quality”, available as PDF
- Gretchen Hargis, et al., “Task-Oriented Writing for Techies“
- Wikipedia on software metrics which has the Tom DeMarco quote
Your turn
Do you estimate your efforts ahead of time? Is it worth the extra effort? How do you use the numbers to your advantage? Please leave a comment.
Filed under: lone writer, metrics, structured writing, topic-based authoring, users, writing |
Kai's Tech Writing Blog 
I wrote up how I’ve tackled this in the past: http://www.onemanwrites.co.uk/2009/01/13/the-black-art-of-estimation/
And everything you’ve said holds true with experience ending up trumping everything.
Thanks, Gordon, for the pointer to your very helpful, complementary post!
Funny how estimation seems a bit mystical: Your post alludes to the “black art”, my post was initially called “Zen and the Art of Estimation”… 🙂
This is a fantastic article, Kai, on the whys and the hows of estimating.
Besides documenting your estimates for all to see, you should also document the assumptions on which the estimates are based. This way, while you’ll still be held accountable for your results, you’ll also have a way to hold accountable those on whom you have dependencies. I think you may have had this in mind when you wrote your “transparency” section.
Thank you, Larry, for teasing out what I had in mind.
Yes, the transparency is also about holding accountable the “other guys”. I find the most crucial factors are the quality and completeness of specs and designs and the timeliness of reviews.
Most of the other interdependencies I can work around to some degree and for some time. Yes, even a missing product – which I think is one of the moments “when it is correct to write technical fiction“…
With big projects and multiple products/teams, estimation is essential to show the project managers/teams that documenting takes time and effort. Our group estimates by writer-tasks to show what we do (education of our ‘clients’) and to show that documentation group works with quantifiable and repeatable approach. It’s a pseudo-scientific method of coming up with an estimate. In reality, our approach is similar to Gordon McLean’s.
We use a spreadsheet to automate this process. It uses formulas and it’s based on a co-worker’s estimation tool from past development projects. (Thanks, Lu Hall!)
Our formula breaks down the project/team’s scope into concepts, tasks and reference (screen based) content required. (Neat how this matches the DITA topics, ain’t it!) From this, we come up with a number of topics we’ll need to create for each – this is the categorization of the content, generally based on a very rudimentary analysis of scope. Then we use our past experience with various teams/work to come up with a number of how long it would normally take to create each type of content. That is, for this group, an easy concept would take 1 hour, a moderate one 1.5 hours and a complex one 2.5 hours. Repeat for tasks and references (based on number of screens).
The next step it to break down how much time we anticipate spending on each section of the job of writing. For instance, 20% of a unit is spent on analysis/research, 50% spent on information development, 10% each on testing/building and rework (post-review). Plug the numbers in based on the categorization of the topics and out pops a total. Multiply that by the number of anticipated topics. If necessary, multiply that by an unknown factor – which pads the estimate for scope creep.
Total up the numbers and you’ve got a breakdown of the time spent on each area of the writer’s tasks as well as an estimate for the entire project. I repeat this for a Low estimate (best case scenario) and a High estimate (worse case scenario) that I then average out to pass that over to the project manager.
I try to go back and review our estimate with our actual time, if I can pull the actual time just for one project from our timesheet system. We’ve been pretty close (i.e., within a couple of hours) on large projects and smaller ones for different teams.
The benefits of doing this include (1) generating trust because we use a standard approach and we can justify where the numbers come from, and (2) educating coworkers about what tasks are involved in writing. I make sure to mention to the PMs that my estimate does not include SME effort – that’s the PM’s job to assign. I have found that this saves me from trying to control something (or someone) that’s out of my realm of control and influence, thereby reducing my stress. 🙂
Karen Lowe
Karen, thank you very much for sharing your experiences and best practices. It’s more like a guest post than a comment and much appreciated!
My approach is similar, I guess: My efforts for easy / moderate / complex topics are in the same realm as yours. I haven’t broken down the efforts as you have to analysis/research + info development + testing/building + post-review work, so that’s an instructive indication.
I’d be curious to hear how the 3-point estimations have been going: Do you often wind up with a best or worst case scenario? For each release, I have 10-15% best case, 2 or 3 instances of worst case and everything else is on the middle level.
And congratulations on keeping the SME’s out of your schedule and budget, a wise choice and good move!
I’d just like to add a couple of notes to Karen’s topic;
This original estimating method did come from an application development project (almost 15 years ago now). It was a team effort and I’ve gotten great value from it over the years as both a developer and as a technical writer.
The concept of duplicating the estimate for best and worst case scenario is another developer’s estimating technique. I think it’s useful when you’re breaking new ground, doing something you’ve never done before and/or using new technologies and you don’t have any past projects to base your numbers on. For standard projects, using standard practices and proven technologies, I agree with Kai’s original comment on estimating efficiently. While it doesn’t take all that much extra time when you’ve got a well-defined spreadsheet, I don’t think it’s necessary (i.e. trust your experience). And the law-of-averages works well with this method too. Each individual task may be under or over the time estimated, but in my experience, they tend to balance out over the life of the project.
The concept of using an ‘unknown’ multiplier isn’t an excellent tool to help you nail down the scope of a project. When a client sees this and the effect it has on the timeframes, they are generally pretty quick to come to the table with some answers for you.
Thanks, Lu, for your comment – I had suspected as much: The estimation method Karen generously described does remind me of how developers do their estimations.
I’ve used an “unknown” multiplier when I first started estimating efforts – mainly to cover my back, I’ll admit. I’ve since shelved it, because I found it less and less useful. Instead, I can now – with some luck – marvel my manager with pretty precise premonitions (and gratuitous alliterations… 😉 ).