It is important for the buyer of localization to have a good grasp on the total cost of localization, not only for comparing localization alternatives, but also for use as a communication tool with prod­uct management and corporate management. The total cost of localization typically is comprised of these costs:

Ÿ           Internal costs – Contract administration, localization project management, technical support for handoffs to the localization provider, training and Q&A, and finally company reviewers (and testers) responsible for the approval of termi­nology, style, and final deliverables.

Ÿ           External costs – Approved, original (baseline) budgets stated in the provider’s Statement of Work and any approved Change Orders. This includes both ini­tial localization and ongoing localization updates, until retirement of the product.

Ÿ           Cost of delay if the planned release dates are missed.

Ÿ           Cost of any rework if the localization provider fails to meet quality requirements. This also includes clean up of glossaries and translation memories when switching providers for quality reasons.

More and more, corporate management wants localiza­tion decisions to be based on some form of return on in­vestment considerations. Return on investment compares the above costs with projected revenues.

The localization project manager on the buyer’s side typically has little insight or control over revenue projec­tions for localized products. Even historical data is often not readily accessible since revenues are often recorded by region, not by localized version of the software. Dis­tribution of multiple localized builds in a single SKU and grey market revenues further complicate the picture. Therefore, in this article, we focus on the cost side that the buyer’s localization project manager can control and capture.

Most companies fail to track internal costs of localization adequately. If there is no project-oriented financial reporting available for local­ization projects, the buyer’s localization project manager should estimate the costs.

Acquiring the data necessary to estimate the costs can sometimes be a mystery. I recommend using average burdened rates provided by HR or Accounting and workload estimates based on metrics (such as the time to review 100 pages of localized documentation) or historical data. It is important to re­fine these estimates from project to project by querying those involved after completion of their tasks.

Determining the cost of delay can also be a mystery. A generally accepted approach is to take a year or six months of projected revenues for the localized product and calculate the average daily revenue. This equates to the cost of delay for each day of slippage of the localized product release.

The cost of rework is very situation dependent and can typically only be estimated once the harm is done and understood.

Quality of communication

Although hard to express in monetary units, the quality of informal and formal communication strongly impacts the total cost of localization. Good informal and formal communication will substantially reduce the risk of bud­get and schedule overruns.

Payment terms (milestones driven, tied to acceptance of final deliverables, penalty terms for late delivery) also impact the total cost of localization. Payments connected to milestones and even penalties on late delivery provide additional motivation for the provider to meet project objectives in terms of quality, time, and schedule.

Localizability

Sadly enough, many corporations do not take into account (nor track) the total cost of localization when it comes to making decisions such as provider selection, contract negotiation, provider switching, and last but not least, “go no-go” decisions on lo­calization. There seems to be a misplaced fascina­tion in this industry with getting the lowest possible rates on services offered by localization providers, often resulting in decisions that do not lead to the lowest possible total cost of localization. In my ex­perience, the single largest contributor to the total cost of localization is the localizability of the soft­ware and its documentation. Following are some best practices that help keep costs under control:

Ÿ           Have a well-defined architecture and processes for the externalization of GUI strings and messages.

Ÿ           Have a well-defined architecture and processes for locale tracking and for detection on the user level and data level.

Ÿ           Use coding standards that take into account sound internationalization principles.

Ÿ           Encourage early adoption of Unicode Standard conformity.

Ÿ           Perform early testing of internationalization features and assign adequate priority to in­ternationalization defects.

Ÿ           Create well-structured and documented localization kits that are complete, but that do not contain extraneous files or details.

Ÿ           Develop well-defined localization test plans that include insight on what does not need to be tested, especially in the case of minor releases. This requires early and close inter­action between the baseline QA team and the localization provider’s QA manager.

Ÿ           Write the documentation with an internation­ al audience in mind.

Ÿ           Use single sourcing for online help and other forms of documentation through conditional text.

Ÿ           Keep tight control over the growth of docu­mentation with each new software release.

Ÿ           Where possible, tie the documentation to the functionality, not to the specifics of the User Interface. If that latter documentation approach is really needed, a red flag should be raised regarding the usability of the ap­plication.

Scope control and change orders

Ouch! You followed all that advice and really looked at the total cost of localization—but now your provider is confronting you with major budget overruns.

“An outrage!” you cry.

However, in most cases (but not all) the provider is not completely at fault.

So what did go wrong? Well, your localization bud­get is based on the information available at the time of budget creation. Since then, you have been handing off updates of the English source files for GUI  strings, mes­sages, help, and other documentation to your provider, and your expectations for growth and change of the­seGUI strings, messages, and information content were grossly optimistic.

So how can you avoid this painful scope creep? Here are some guidelines:

Ÿ           Demand of your documentation department a commitment to maximum page and word counts as part of the documentation plan. The same can be done in regards to GUI strings and messages, but the impact of growth from the GUI is typically much less than the impact of growth from docu­mentation and help.

Ÿ           Get commitment to guidelines for changing docu­mentation. In other words, what changes have an acceptable quality increase/cost ratio?

Ÿ           Track the amount of changed and new strings (as reported by translation memory systems), both for software and documentation. If you do not have the means to obtain this internally, you can at least demand of your provider to provide this type of analysis at each new hand off of English source files.

Ÿ           Limit or at least strictly control the number of  handoffs of English source files to the provider, since each additional handoff carries an overhead in terms of time and cost.

Ÿ           Clearly define under what circumstances you ex­pect your provider to negotiate a new baseline for budget and schedule (typically referred to as a Change Order).

Ÿ           Insist on formal approval of the original baseline for the localization budget and schedule (as spec­ified in the provider’s Statement of Work) and each new baseline (as specified in the Change Or­der) before the provider does any work. Yes, this impacts your schedule, but you need to plan for this additional time from the very beginning.

Survival tactics

How can you survive as a project manager out there in the localization jungle? Here are a few suggestions:

Ÿ           Make sure that you understand the degree of localizability of the products for which you are respon­sible.

Ÿ           Always try to form a complete picture of localization costs. In particular, estimate internal costs as part of the total cost of localization.

Ÿ           Make sure the localization provider’s project man­  ager who is going to manage your project is directly involved in the creation of the Statement of Work. If he or she is not involved, consider this a major risk for budget and/or schedule overruns.

Ÿ           Insist on the localization provider giving you a firm,  fixed quote in their SOW. This insures that any bud­get overruns are caused by scope increases initi­ated by you: New English source files with changes and new words, new components to localize, ad­ditional services or locales requested, etc.

Ÿ           The last payment for your provider (typically 30%)  should only be released after careful approval of the final deliverables.

Ÿ           Require an impact analysis (budget and schedule) from your provider for each additional handoff of English source files.

Ÿ           Require formal approval of the SOW and any subsequent Change Orders before work proceeds. Pro­vide time for this in your localization schedule.

Ÿ           Track growth in GUI strings, Help, and documentation, so that you can anticipate Change Orders from your provider.

Ÿ           Spend time at the start of the project to go over informal and formal communication with your pro­vider’s project manager. In particular, carefully review the status report template to make sure it provides you with all the necessary cost and time information.

Ÿ           Make sure that training is provided to the provider’s  localization team, especially in the case of: a new provider, a new product, or a major release. Local­ization is only as good as the product understanding of the localization team.

In closing

Understand the localizability of your products, hold documentation accountable for a target maximum page or word count, and keep a close eye on the stats pro­duced by your provider in regards to change and growth in GUI strings, help, and other content.