Point Blank Translation

By Willem Stoller,
Welocalize

You know what I mean…

Jumping to conclusions, taking things for granted, we all have been there! Localization projects often run awry because of imprecise or implicit communications. In particular when it comes to deliverables (You need those html files compiled into a .chm?) and services to perform (You expect who to build this software?) for a particular project.

Extracting through dialog the true localization requirements from the client and managing client expectations over the course of the project are crucial activities for all Localization Project Managers. Some examples of those project requirements are:

What are the intermediate and final deliverables? A clear description of all intermediate and final project deliverables is crucial. Project deliverables include all product deliverables, plus project-specific items such as progress reports, defect reports, completed check lists, translation memories, glossaries, etc.
What is the timetable for all deliverables? How are the deadlines classified (desired, critical, etc.)? Sometimes we are dealing with very “hard” deadlines such as tradeshows and this increases project risk
What is the budget for the project? How are variances handled? Is this a “time and materials project” or a firm, fixed-cost one? This should also cover setting clear expectations about change orders.
What is the budget for the project? How are variances handled? Is this a “time and materials project” or a firm, fixed-cost one? This should also cover setting clear expectations about change orders.

There is more to communication than that; during project execution it is important to communicate clearly what is required from each team member. Failing to do so results in rework, unassigned activities and general frustration among the team members. That brings us to our next topic...

NO TIME TO PLAN…

You have spent substantial time negotiating requirements, budgets and deadlines. Now the deal is closed and both vendor and client want to get on with the project and start the translation activities. In most cases your deadlines are already tight to start with and the last thing you want to do spend some more time on planning activities before delving into translation. It is very tempting, but the knowledge that most projects fail due to either misunderstood requirements or lack of planning ought to make you think twice.

Now is the time to complete planning in terms of project approach, resource allocations, deadlines for all intermediate deliverables, risk management, etc.

This is best done through a detailed project plan that can serve as:

A roadmap for everyone involved, i.e. the stakeholders, in the project. It will outline project phases, and it will indicate how activities and milestones within the phases are dependent on each other. Additionally, it will document the deadlines for all project deliverables.
A clear description of each stakeholder’s responsibilities. I like using a Linear Responsibility Chart (a table with the left column identifying all project deliverables and the rest of the columns identifying each stakeholder). The cross-section of the two columns specifies one or more of the following responsibilities of each stakeholder for a project deliverable: create, review, approve or not applicable.
A metric against which to measure project performance in terms of progress, money spent and quality. A baseline schedule in Gantt chart format provides a simple way to compare planned versus actual performance. Cumulative budget versus actual cost comparisons provide good indicators of financial performance.

I hear you saying: “I have no time to write a 50-page project plan” and you are right. The amount of detail to be covered in the project plan is a function of:

Number of stakeholders, in particular team size
Complexity of project and product
Localization maturity of client
Number of deliverables
Use of new technology

For most localization projects a well thought-out MS Project schedule complete with resource assignments, notes describing deliverables and constraints and all budgetary information will be enough documentation.

Also, during this planning phase you can do some activities in parallel such as the preparation of translation kits, glossary translation, initial client reviewer meetings, etc.

Now you might think once I understand the requirements and I have done my planning homework it will be smooth sailing? The next topics will highlight some other reefs you might shipwreck on.

SLIP SLIDING AWAY…

As a vendor project manager you have a number of conflicting objectives:

Keep your client happy and meet his/her expectations in terms of deadlines, quality and budget
Keep your own management happy in terms of gross margin per project and overall throughput in terms of projects

One of the easiest ways to please the client is to accept any and all changes with a smile and can-do attitude. Follow this line of reasoning and you will soon meet your nemesis scope creep, resulting in missed deadlines, lowered margins and general dissatisfaction both for your client and your own management.

How can we have a “can do” attitude and still keep control over the scope of your project? If you did a good job on defining requirements and initial project planning you will start your project with a well-defined scope. To keep this scope under control requires a formal procedure for approving any change to the original scope of the project; not doing so is setting yourself up for failure.

Scope control on localization projects involves:

During the proposal and planning phases discuss in detail how change will be managed through change orders.
For each scope change generate a timely Change Order. The key here is timely: as soon as a scope change has been requested and not at the end of the project!
Communicate, discuss and obtain approval for each change order based on its impact on project objectives (schedule, budget, functionality and quality)
Use version control software and translation memory to keep track of versions of source files and localized files.
Also using a tool to manage resource allocations across all project (e.g. MS Project Server) helps you to assess the impact of scope changes on your own and other projects.

The most common scope changes involve: updated source files, additional locales and additional deliverables. In some situations it is better to treat the request as a new project instead of a change order, especially if this request involves new deliverables.

A good rule to remember is that your project scope should include everything that is essential to meet project objectives and nothing else.

THE REVIEWER: A REBEL IN DISGUISE?

Our last failure scenario is unique to localization projects: The role of client reviewers and their potential impact on the project. For most localization projects one of the final project milestones is formal acceptance of the product deliverables by your client. Typically there will be one or more reviewers for each localized version of the product.

Unlike software development projects, localization and translation projects have subjective quality requirements due to the nature of natural language. In particular terminology and style are subjective and mostly determined by the client reviewer’s preferences.

It is critical to capture correctly the terminology and style requirements as seen by the Client’s reviewers early in the project and subsequently managing those Client reviewers’ expectations.

During the planning phase of the project you need to get client reviewers identified and you should develop a trust relation with these reviewers. Often you are dealing with sales or marketing staff in country that got saddled with the review responsibility on top of their normal duties.

More dangerous to your project are those reviewers who do not accept “corporate control” over product localization. They will not like your localization because they had no say in the original English version and they feel that their particular market deserves a much greater degree of locale adaptation than that corporate management is willing to pay for. This situation presents itself in particular for marketing and training materials (web or off-line). As a localization project manager you might stumble into such a corporate minefield and find that localization quality is used as a weapon in the struggle for control between different parts of the client organization.

It is next to impossible to recover from such a failure scenario, therefore during the planning phase adequate time needs to be spent on the role of the reviewers. Clearly defining the review process and assuring the early involvement of these reviewers in determining terminology and style is your best bet in avoiding this potential minefield.

IN CLOSING…

Localization project management requires a very pro-active “can do” attitude combined with strong analytical skills. The complex task of localization project management is best illustrated in the diagram below: