Even though the tools and technologies of our industry are advanced, new clients are generally not well versed in localization. They often discover their need for localization late, and then, too quickly, services are bought, or a new team is built, without realizing the real needs. Implementing a localization process that does not suit a company can have dire consequences, resulting in technically failed projects, financial losses in localization projects, and bloated human resource costs.
In the case of outsourced services, ill-suited localization solutions occur for several reasons: Vendors often lack the necessary insight into the companies they are trying to service. Also, vendors achieve much of their profits from value-added services other than translation, which gives rise to the temptation to add these services into a client’s processes. Vendors do this to bring the quality level to that which they, the vendors, see as an acceptable level. However, it is not necessarily the level that the client is aiming at or that organic growth requires.
What this means is that vendor localization models are being imported into client-side operations without clients being knowledgeable of all the alternatives.
Often, the grounds for selecting a localization model are misguided. Someone makes a specific concept and process successful, and then offers it as universal. The temptation to pick a large corporation with excellent international revenue as a role model for a mid-size expanding company is very dangerous, indeed. This often results in large-scale investments and high maintenance costs, even before the first project is started. This immediately makes the expansion financially risky. In addition, large-scale investments can have an adverse effect on a company’s localization strategy. They further tempt the company into stepping into international expansion at a scale larger than what the current company structure can support financially.
For some companies, this may be the way to go. However, there is also a different way.
A Dynamic Process
The field of Information Security is very dynamic and fast moving. Responding to the external threats that harass our customers requires a great deal of flexibility from development. Projects are constantly re-scoped, as new features are always needed. This means that localization needs to respect the need for changes, fluctuating schedules, and relatively short product lifecycles. In localization terms, this means that we have had to improve and innovate considerably in the areas of reusability (for financial reasons), resource consumption (for timing), and flexibility (for implementing last-minute changes).
So far, our approach to localization has proven successful. Of course, success is a relative term, and our definition of success is explained below. For now, let’s just say that we have had very few failures. Moreover, our localization department has managed to accommodate the growth of our company and its demand for increasing volumes of localized content, while maintaining a team of only three persons over the past six years.
We have accomplished this under the following workload: On average, we support four to five major releases during the year and support a constant flow of effect on overall company strategy (extending product selection in existing markets). The absence of a rigid, complex process—in other words, dynamic project management—allows us to use a wider variety of methods to achieve a product’s target state. We also can make less-critical decisions with considerably less effort and less cost. minor projects (minor releases, marketing, and miscellaneous linguistic services). The number of languages varies between four and 15. The number of platforms varies between one and six, ranging from hand-held devices to server environments. We are involved in all projects, starting from the business case and ending with the handoff to the release team. We run localization subprojects as well as main projects. We outsource translation and a portion of the testing, but perform most of the remaining localization value-added services in-house. We also own the localization budget.
In a dynamic localization model, success depends on the project and the target for the project. Each project is evaluated regularly throughout its duration, to minimize risks, but also to ensure that no more or less is done than what is needed to achieve the target product. In our view, success is delivering what is asked for, not over performing or under performing. We measure the success or failure of a project, using three indicators:
Financial viability –A project that results in a profitable product (projected revenues outweigh current and future costs) is considered successful.
Enabling sales –Localization is sales support. Therefore, it’s critical to evaluate whether localizing a product into a language enables sales, either directly or indirectly. Putting a price tag on enabling sales in a region—before revenue is actually generated—is difficult. It is achievable, however, through good business-case planning.
Perceived quality –What is good enough? What level of quality is acceptable, considering the investment, the corporate strategy, and the current business case? Of course, the functionality of the product must be intact, but the level of acceptable cosmetic and linguistic bugs must be evaluated, and then measured against the degree of quality that allows continuing on the projected sales path in a region.
Ultimately, for a project to be considered successful, at least two of the three indicators must be fulfilled. Aiming for all three often increases the expenditure for the project exponentially, both in direct costs (outsourcing costs) and indirect costs (extended project schedule, in-house resource consumption, and loss of market time).
In a dynamic localization process, the ownership of the localization project must lie within the localization team. Thisteam should have the necessary expertise and the responsibility.Other contributors are limited. They contribute only through a project steering group. Even then, discussions are limited, to avoid the committee effect, where more time, and thus, more money, is spent than would be gained by having the localization team simply make the decision.
In order to maintain a high degree of flexibility, we have adopted a light structure or workflow to our projects. This workflow allows many customizations. The key steps in the workflow are listed below.
Evaluation –This first phase actually has two stages. The first stage involves a risk evaluation and documenting the product target state (using the success indicators listed above). In the second stage, the first-stage documents are evaluated, enabling a decision on the project. There are three possible outcomes: stop, hold, and go.
We use different evaluation tools and methods for different projects. We use lighter evaluation methods for projects that do not require formal data or for projects where formal data is unavailable (new smaller markets, enabling sales). We use more complex tools and methods to evaluate projects that have higher requirements.
Implementation –Once a product’s target state is initially defined, the plan is evaluated throughout the development stage. It is re-evaluated each time there is a possible significant change in the desired target state. Suppose a language or a new feature is added.
In order to achieve this degree of flexibility, the implementation phase relies heavily on using outsourced temporary resources, especially for translation. If we were to use in-house resources, we would already be paying for the scope of work for a predefined project. Additionally, if the project is re-scoped to include more work, we would have a resource problem. On the other hand, if the project is put on hold or reduced in scope, we would have costly resources whose work would be forfeited, but would still be counted as expenditure in the project. Using temporary resources allows us to change the scope of the project dynamically, without losing extensive amounts of work and money.
Another practice that enables flexibility is dividing the workload or project deliverables into components. This allows us to prioritize components that are least likely to change, saving us from costly updates.
Also during the implementation phase, we use an open interface to our vendors. Instead of stipulating all tools a vendor should use, we are more concerned with a vendor’s processes. By allowing vendors to use the tools they are already familiar with, we receive all the benefits of the training in which the vendors have invested for their own resources. We trust that the process, not the tools, is the guarantee of quality we require.
Validation –This involves validating the outcome of the implementation phase against the prevailing target-state definition. Depending on the product, the validation process can range from a full-blown, major-release validation effort, including outsourced linguistic testing, partner validation, and beta testing, to a minor market-specific test release effort, where the customer validates.
Release and Repeat –Throughout the project, the process itself is also reviewed and evaluated. Clear improvements can be implemented quickly, piloted on slightly later parallel projects. This way, we keep the cycle between process improvements relatively short.
Team Dynamics and Continuous Improvement
Maybe the greatest resource in the dynamic localization process is the localization team itself. A dynamic process requires the team to be flexible and open-minded. The resources in such a team should be fast learners who are not overly protective about their work and position. This requires a mindset geared toward doing things together, sharing knowledge, and granting visibility to each member for the work they do. The following paragraphs briefly address some of the team and self-improvement dynamics that either are the result of, or have contributed to, our localization model.
Team Structure –Our team structure consists of two coordinators and a problem solver. Coincidentally, the problem solver is also the manager. A small team allows us to communicate with each other efficiently and to keep an eye on each other’s projects.
Problem Solving –Problem solving is the single greatest task in a dynamic localization model. Problems help us learn. Thus, when a challenge is escalated to problem status, the whole team is involved in dissecting the problem and determining a solution, even though it might be the problem solver’sjob to own the solution and take the heat, if necessary. By solving problems together, we learn new thought patterns and new problem-solving models that can be applied in the future.
Knowledge Transfer –Doing things together also means fast, first-hand knowledge transfer. In order to keep the skills and knowledge in the team rounded out, we regularly stop and teach each other the things we have learned individually. This way, any team member can provide help when it’s needed.
Improving Things –In a good dynamic environment, new improvement suggestions are constant. If the whole team feels a suggestion is worth trying, it is usually implemented. Roughly, 9 out of 10 suggestions never make it.
The Big Picture –In our dynamic model, the whole team has access to the big picture. Each team member alerts others to the small changes in a project that can eventually affect other projects. In other words, each team member tries to see beyond the individual project for the mutual good.
A dynamic localization process such as the one described here might not be suitable for everyone or for companies of every size. Still, I believe this model to be a good choice if you are just starting localization and international expansion, or if you are streamlining your current organization. This model allows you to start small and progress organically, without creating too much of a strain on the rest of the organization. In essence, this model allows you to do what localization is all about: to produce financially viable support for your company’s plans in the international marketplace, with the right quality for the right price.