by Dick Weisinger

If your company wants to successfully compete and sell software in the global market, product localization is essential. But when you don't have the experience or the resources to handle the work internally, what can you do? An increasingly common solution is to bring in a team of localization experts. There are lots of localization vendors to choose from, many of whom provide complete "one-stop" shopping services.

Outsourcing, after all, seems an easy solution. (Even Microsoft relies heavily on outsourcing for translation and localization services.) Why interview and hire a staff of in-house specialists to do a job that likely will cycle wildly between crunch and idle times? Subcontracting to localization experts who know their business frees your company to concentrate on its core competencies, and offshore localization pricing can be very attractive.

The reality, however, is that while the potential advantages are tremendous, outsourcing is often not as easy or as risk-free as it initially seems. If you fail to consider the full implications when making the decision to use outsourcing, problems can (and probably will) arise.

Outsourcing localization
The task of the localization outsourcer is to modify your software so that it meets the needs of the market in a particular locale. This doesn't mean that localization changes are superficial to the main functionality of your product; the importance of quality localization can't be minimized. The localization outsourcer shares a large responsibility in creating the image your product presents in the target locale market, and the quality of the localized packaging, user interface, and documentation is what makes a first impression on potential customers.

Most localization outsourcing companies offer project management as a part of their package of services. Thus, it might be easy to conclude that once the outsourcer begins work, the localization process is no longer your problem and you can move on to other things. This kind of thinking can prove disastrous! Your company bears ultimate responsibility for your final product; it is your company's name and reputation, not that of the outsourcer, which will be displayed on the software. Mismanaged outsourcing can lead to a number of undesirable results, including poor quality, cost overruns, and significant slips in schedules. But such problems don't have to happen.

Based on recent experience with a Japanese localization outsourcing project, I've put together a seven-step plan to help in the decision on whether to outsource your localization project. Follow these steps, and you may manage to stay smiling during the whole localization process.

Step One: Determine whether outsourcing is the best strategy
If you don't use outsourcing, what are your other options? The obvious answer is to do the work in-house, but you may not need to go it totally on your own.

Unless you are a giant like Microsoft, you probably rely heavily on a distribution partner in Japan. Whenever possible, use your distributor. Your distributor knows the Japanese market and can provide valuable advice about translation, packaging, documentation, and just about anything else you need to do. So, spend the time to get as much information as you can from your distributor.

Beyond advice, your distributor may also be able to provide translators, testers, and maybe even engineers. They are probably as anxious as you are to begin selling your product; they want to help. It can be difficult for them to begin their sales effort without at least a localized alpha or beta version of the product to show.

If you decide, after careful consideration, that outsourcing is the best approach, consult again with your distributor. They know the market, and are probably in a good position to assess the skills and quality of outsourcing companies and consultants within your software specialty.

Step Two: Write a detailed Requirements Specification
It's only natural to want to jump in and "just do it," but don't skip this step! Trying to proceed without a high-quality detailed Requirements Specification will lead to serious trouble further down the road. The Requirements Specification forms the basis of the Request for Proposal that you will send out to localization service vendors, and it often will become part of the legal contract.

The requirements document should detail the complete scope of the project, including specifics like which products, which modules, and which platforms are to be included. Make sure you identify and describe, as exhaustively as possible, the areas for localization in each of your target products and modules. This includes details about text appearing in screens, internal text handling and storage, and input/output, as well as other requirements regarding the tools, methodologies, and development environments to be used. There may also be further requirements regarding software documentation, engineering data, backup procedures, and source code control.

For Japanese localization, in particular, one point to spell out carefully in the requirements document is how and which character sets will be supported by your product. Computing environments involving multiple hardware platforms, such as client/server systems, can add the complication of managing multiple character sets. In an environment that uses a Unix SUN server and PC clients, for example, the SUN uses the EUC character set and the PC uses Shift-JIS. If text data or files are to be interchanged between these machines, it may be necessary to convert between the character sets.

Preparing a detailed requirements document prior to soliciting bids will put you in control when negotiating with and selecting your potential outsourcer. It will also give you a ballpark idea about project cost and time requirements even before you solicit a bid for the job. Further, a clearly written specification will allow you to accurately compare bids and avoid many later misunderstandings with your outsourcing partner.

If you don't have the expertise or resources to write the requirements specification yourself, consider contracting the task to an experienced (and disinterested) third-party. Using outsourcing consultants in preliminary planning is becoming quite common. Again, it may be best to consult with your distributor first about how to proceed.

Step Three: Prepare an integration plan
Plan in advance how you will integrate each of the deliverables identified by the requirements document into the product, your organization, and your distributor's organization. This plan is for internal use within your organization. For example, you may want to integrate parts of the code added for localization into subsequent releases of your base product (to simplify future localization efforts). Production and shipping all need to be coordinated. And acceptance testing and proofing of the deliverables (by you and/or your distributor) need be scheduled.

A localization test plan is vital. Testing can easily comprise the bulk of the effort required to do localization successfully, so take care to ensure that quality assurance and testing resources are wisely used. For example, your outsourcer will test, you very likely will want to test the final product, and your distributor may do acceptance testing. But if you are not careful, there is a tendency that a lot of very shallow testing may be done on the assumption that more thorough testing was or will be done by someone else.

Also, don't forget about developing a support plan that specifies how customer issues will be dealt with once localization is complete. What level of communication and bug-fix support will you need from your outsourcer, and what kind of turnaround can you expect?

Step Four: Allocate a budget
The requirements document and integration plan will provide a good estimate of the costs and resources needed to complete your localization project. Before proceeding, your next task as the buyer must be to ensure that an adequate budget and resources will be available for your project.

If you've gotten this far, and this is your first product localization, you'll have found that the cost is an eye-opener; localization can be very expensive. It may be too late for this project, but you may want to step back and consider how you can reduce the costs and effort required for the localization of the next version of your product.

In particular, if you are localizing for more than one language, you can save the costs of redundancy during multiple localization processes by first "internationalizing" your product. Internationalization is the initial step that prepares your software for easier support of multilingual computing environments, and simplifies the process of localizing it for specific locales. If internationalization is done correctly from the beginning, it will dramatically cut the time and expense required for localization into a particular language.

Be aware, too, of possible hidden infrastructure costs involved with getting your outsourcer set up. For example, it may be necessary to purchase and configure a mirror development environment for your outsourcing partner. This will be especially true if your software runs on machines or operating systems that the outsourcer does not already have; be prepared to supply machines, operating systems, and additional development tool software licenses (since your site licenses may not extend to your outsourcer's site). And don't forget both the user-level and developer-level training that you will need to provide to your outsourcer to get them up to speed quickly on your product.

Continue article

Back to the table of contents