The first real question I get when talking to a prospect about technical writing or creating training materials – after the “personal” pleasantries – is “what’s it going to cost?” Of course, the question is usually qualified by “I know you can’t give me an exact price” or “I’m sure you’ll need a bit more information before you can quote the project” but bottom line, everyone wants to know how much they’re going to have to pay.
No surprise there.
I’m sympathetic to these questions because it’s the first thing I ask when I’m looking for someone to do something for me, whether it’s a carpenter, plumber or auto mechanic. While I’d love to simply say, “Hey, go ahead and fix it,” I do need to know what the job is going to set me back. So I’m not offended or angry when the prospect pops the question, “How much?”
Unlike replacing a set of brakes on my car or fixing a bad valve on a sink where the technician has guidelines and experience of having done the same thing many times before, there are no guidelines for technical writing for how long it’s going to take to write a user guide for a piece of software. While every Toyota Corolla for a given year has similar braking systems and parts and therefore fixed prices for parts and labor, no piece of software is the same. Even when the software is “close” to something we’ve done before, it’s never identical. And what 25 years dealing with all kinds of companies and people has taught us, no company is the same. We’ve worked with companies that have excellent requirements documents and helpful developers who can answer questions and others that have neither. So how do I answer “what’s it cost?”
It’s difficult, for sure, but not impossible. What we’ve learned – and we’ve burned, once estimating a project at 100 hours that took 200; didn’t make any money on that one! – is that we can break the project into the smallest pieces possible and then assign an estimated time to each little piece. I’ve even had a writer assign the number of minutes he thought it would take to document each function in a piece of software. I wouldn’t recommend that approach – I thought it was a bit over the top – but for him it worked and his estimates were pretty accurate.
Of course, having 25 years of experience doing this doesn’t hurt either. Like my plumber who knows how long it’s taken him to replace a part because he’s done it so many times, we’ve worked on enough applications to be able to determine about what we think it’s going to take to finish the project. And while we have made some costly mistakes, we’ve learned from these mistakes and now spend a little more time on the proposal so we can avoid losing money.