The delivery schedule is a two-way street, particularly when dealing with software UI localization where your developers and engineers need to incorporate the newly translated material into the software build that is going to be sent for testing. The vendor needs to know when new material will be ready for translation in order to schedule the translation resources. And the developers need to know when the translated material will be delivered so that they can properly establish their build schedule, and so that you can plan your functional and linguistic testing timetable.
Deliveries in the localization business are variously referred to as ��drops��, ��bundles�� or ��batches��. These words refer to deliveries in both directions.
Your developers will tell you how long it will take them to integrate the translated material into their build. You can then plan on testing that build if you want to. But those engineering times must be taken into account.
It is best to plan the batches for the duration of the entire project, and place periodic buffers for the inevitable surprises. This gives you a strong handle on the planning, and will enable you to have a clear vision of the project process, allowing you to foresee problems and prevent overruns.
Sometimes your engineers will supply you with a tiny piece of source material that must be translated, and they would like it done quickly, because it may be a vital test piece or it may solve a functional bug. But translating it may not be so simple.
Some customers, particularly large ones that have multi-million dollar annual translation budgets, have a streaming arrangement with their vendors. In such an arrangement, the volume is so great and fairly predictable, that budget analysis, estimate and approval is not required for every bundle. Payments are made at pre-set milestones based on the work actually done. In such a case, the sending of small, unscheduled pieces is not a problem.
However, in many cases, each bundle has to have an estimate made by the vendor, which then needs to be approved by the customer, before the translation work is begun. While it naturally takes longer for the vendor to create an estimate for a large bundle than it does for a small one, there is much common overhead for this process so that for small bundles, the estimation work can actually take longer than the translation work. Many vendors like to know ahead of time when they are due to receive bundles, or at least when they are likely to receive bundles, so that they can assign the necessary management resources ahead of time, to do the estimation work.
If you don��t have specific dates for bundle deliveries, or if there are likely to be a lot of surprises sprung on you by the developers (not necessarily their fault), you should consider implementing a delivery ��bus�� arrangement with your developers and your vendor. You tell the developers and the vendor that the ��bus�� will ��leave�� at a certain time on a certain day, say close of business every other Tuesday. That way the vendor knows that Wednesday morning, he should assign management time to deal with estimate work from you. And your developers should know that they need to prepare all the required source material for that bus��s departure. Whatever is on the bus will be dealt with by the developer. And whatever misses the bus has missed it.
A similar bus arrangement can be implemented for returning material too, so that the developers can assign build creation time in advance.
The value of the bus depends upon translation volume and the arrangements you have with your vendor. But it can be a helpful approach that can avoid a lot of surprises and difficulties.