Estimating #techcomm projects: More science to go with the art

The pig lizard from Galaxy Quest: With any luck my cost estimate will fare better than he did.

My friend Ralph has been in the technical communication business even longer than I have. When I asked him for some pointers on estimating project budgets, he said without hesitation, “You know, it’s more art than science.”

For me, that phrase conjures the friendly alien in Galaxy Quest who said “the operation of the conveyor [transporter] is much more art than science.” That was just before the pig-lizard creature beamed aboard, inside-out, and then exploded all over the conveyor room. Have you ever underestimated a project so badly that it ended up like the pig-lizard? I have.

Although I know Ralph is right, I still wish we had more science to go with the art. I wish we had a few benchmark criteria that we could use for estimating. What that in mind, I’ve listed a few factors that, based on my experience, influence the cost of a project. I’d like your help to add items to this list.

History

The most reliable factor, by far, is actual cost data from previous, comparable projects. The trick is in the word comparable: is the new project similar enough to an old one to justify using the old one as a starting point?

There’s also the matter of having accurate data from the old project. We any costs hidden from the project’s final balance sheet — for example, translation costs that were borne by the engineering or marketing department?

For me, it’s increasingly unlikely that I’ll find a comparable project to use as a starting point. More and more, each project seems to be a project unto itself. So I’m left having to consider other factors….

Scope of work

This one should be easy, right? How much does the reader need to know in order to do the tasks they’re trying to do? In practice, the answers are often hard to pin down — especially when the product and its features are still being designed.

Define the work scope as clearly and crisply as you can in the documentation plan — if for no other reason than you’ll have an easier time justifying a price increase when the scope changes later.

Number and type of reviews

When a client insists on seeing lots of review drafts before giving final approval, the writers inevitably end up rewriting content they’ve already written — sometimes several times.

An all-hands-on-deck technical review costs a lot more than a tightly focused regulatory review. Be sure the client understands the differences between different types of reviews. And help steer them away from reviews that are more costly than they really need.

Project size

It might seem like a smaller project is easier to manage. But project management actually accounts for a bigger bite of the total project cost, percentagewise, on a small project than on a bigger one.

Similarly, if the project calls for information design — like formatting covers and pages for print using the DITA Open Toolkit — those costs are proportionately higher for a small project. It takes the same effort to format pages for a 50-page user guide as for a 500-page product library.

Staff experience level

Experienced writers, who’ve worked with the tools and who have domain knowledge, will be far more productive than inexperienced writers.

Put another way: Anything new — a new subject matter, new document formats, new tools, a new CMS — is going to cost more. New things are often well worth the investment. But don’t kid yourself about how much you’ll need to invest.

---

Applying the science

Even if we know which factors influence cost, we’re still a long way from being able to quantify them. We’ll probably never reach the point where we can assign a weight to each factor and plug it into a formula. (If we do, then someone will be in line for the Nobel Prize in Tech Comm.)

Still, it’s a good start just to know the factors and to be able to describe how they influence costs.

What other factors would you add to the list? Why?

Let’s work together to build a list of cost factors. Together we can tip the balance a little more toward science and away from art.

Postscript – 24 April 2015: Since I wrote this article, Jennifer Yaros has posted two terrific pieces on estimating for documentation and training. Her work answers some of the questions I posed here, and I commend both pieces to you:

• Estimating formulas for documentation and training
• Estimating part 2: using a dependency calculator