: How can a new writer make a realistic estimate of his work rate? This question relates to my earlier question Habits and routines for my first tech writing job which I was told to split into

Vote Up Vote Down

A project manager I worked for used this rule:

whatever amount of time seems about right, double it and go with that

(0)

Vote Up Vote Down

I have an exhaustive list of tasks and approximated times it will take for each one, and then I enter this info in a metrics with a minimum 10% contingency (prefer 20%) to determine man hours. However, one programmer suggested a simpler solution: actual time multiplied by 2. If it will take you one week, tell them two. You have to allow for risks and contigencies, changing priorities, and anything else that inevitably might happen.

(0)

Vote Up Vote Down

Your computing experience is probably the best guide you have. You know from this that a) some part of the translation will be easier than expected; b) some parts will be very tricky. So, ignore the easier parts, estimate how many will be tricky. This you should be able to ascertain from the length and complexity of the material - if you can gauge this. Or can you make a reasonable estimate as to how much is liable to be complex.

Assume you will have to go back to the original translators for these pieces, and that they will take you a long time. In the meantime, you will be able to get on with the rest. So you total time is liable to be defined by these difficult pieces - as per software development.

So I would say, treat it as a software task, like translating user requirements into code applications, and you should get yourself a reasonable idea of whether the estimate is close or not.

(0)

Vote Up Vote Down

Estimates of how long work like this will take are always guesswork. One can make some excellent guesses when one is experienced, but even then, it's advisable for one to take several factors into account:

The difficulty of the material. Have you seen any of the text you'll be translating? If you have, then you already have a rough guide as to how long this will take. I suggest actually doing the cleanup work you'll be doing on a few pages of the material while timing yourself. You can then make an estimate of how much time the core project will take. This is an amazingly simple and useful technique that I do with every editing or rewrite job before quoting a fee or setting any timelines, to avoid surprises for myself or for the client. While this is much simpler with straight text (where you will have a word or page count), I imagine similar techniques can be used with translating an app. (Perhaps another tech writer can chime in about this. How do you estimate the volume of application text? Is there a metric here that's useful?)
Communication issues can also add time to a project. In this case, I'm guessing the documentation team will be in the office where you'll be doing the work? If you come across problems while doing the rewrite that are prohibiting you from proceeding, timely responses to questions from your client will make your job easier. If your only contact is in Japan, you'll have to wait overnight for responses.
Familiarity with the material is also something that can add time to a project. In this case, you have a technical background, but are you familiar with Android's quirks? If not, add a little time to your estimate.

If, after getting a time estimate together, you find that the client's timeline is truly unrealistic, I recommend going to them with this information and discussing the issue. If the two of you truly are at odds here, then this could easily turn into a difficult working situation that it'd be best to avoid. On the other hand, if your estimate is fairly close to what they're looking for, then you have no problems.

(0)