This question relates to my earlier question Habits and routines for my first tech writing job which I was told to split into two parts.

My first technical writing / translation gig starts soon. A Japanese company has offered me a gig helping translate an Android business application + documentation into English. Their staff will do a rough translation, and I will polish it into something reasonably professional.

The client has a clear idea of how long the job will take me, and wants me to spend a fixed number of hours working in their office. I have no way of knowing whether the client’s estimate is realistic.

I need to start making my own estimates as early as possible but, if my computer programming experience is anything to go by, I’m the worst person to do that. If you ask a novice programmer, “How long will it take you to do Job A?” he answers, “A day.” If you break Job A down into sub-jobs and ask, “How long to do A1, A2, ... A10?” he answers, “A week.” If you hold him to that, he burns out in a month.

How do I estimate how long the job will take? How do I avoid the trap of overpromising out of an abundance of enthusiasm and a desire to please the client?

  • I forgot to mention: I'm in Japan, so there are no timezone issues.
    – Pitarou
    Mar 12, 2012 at 15:57

4 Answers 4


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.

  • 2
    I second doing a representative sample of the work and timing yourself to get an estimate. I do this with every new editing client. Mar 12, 2012 at 10:15
  • 1
    Good point about communication issues! I'm likely to be working with some very busy people, who view my questions as a low priority. And, yes, Android does have a few quirks. :-) They've given me an Android phone to play with for now, which helps.
    – Pitarou
    Mar 12, 2012 at 16:01

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.


A project manager I worked for used this rule:

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

  • 1
    Yeah, that's a good rule of thumb. It also means this project is screwed. :-( Hofstadter's Law: It always takes longer than you expect, even when you take Hofstadter's Law into account.
    – Pitarou
    Mar 19, 2012 at 5:10

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.

  • Thanks! Yes, it has a lot in common with “porting” tasks. :-)
    – Pitarou
    Mar 12, 2012 at 16:05
  • I don't understand “So you total time is liable to be deined by ...” Sep 9, 2012 at 22:03
  • @jwpat Typo - I have edited. "Defined by". It means that the total time to do the task should be based on the complex pieces, as the simple pieces should fit in around these and not contribute so much. Sep 10, 2012 at 9:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.