Why do l10n projects fail? Common failure scenarios for localization projects

Why do l10n projects fail? Common failure scenarios for localization projects

By Willem Stoeller,
Project Management Professional

willem . stoeller [at] Welocalize . com

Get the List of 5,400+ Translation Agencies Now!
No Recurring Membership Fees!

willem stoeller photo 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, particularly when it comes to deliverables (You need those html fles compiled into a .chm?) and services (Who you expect who to build this software?).

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

• What are the intermediate and fnal deliverables? A clear description of all intermediate and fnal project deliverables is crucial. Project deliverables include all product deliverables, plus project-spe-cifc items such as progress reports, defect reports, completed checklists, translation memories, glossaries, etc.

• What is the timetable for all deliverables? How are the deadlines classifed: desired, critical? Sometimes we are dealing with “hard” deadlines such as Tradeshows which increase project risk.

• What is the budget for the project? How are variances handled? Is this a “time and materials” project or a frm, fxed-cost project? This should also cover setting clear expectations about change orders.

• What are the customer expectations for quality in the fnal deliverables? Establishing quality criteria at the beginning of a project helps greatly in setting the right expectations. Quality criteria are diffcult for localization work, since there is much subjectivity involved in style and terminology.

• What are the customer’s expectations in terms of his/her responsibilities on the project? We all have been caught at least once in a situation where a client failed to meet delivery deadlines for source updates or reviews. The client needs to understand the schedule and budget implications of those delays. The right time to set those expectations is during the planning phase of the project, not after the delays have materialized.

There is more to communication than that. It is important to clearly communicate what is required from each team member during project execution: 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. Both vendor and client want to get on with the project and start the translation activities. In most cases, your deadlines are already tight. The last thing you want to do is spend more time on planning activities. It is very tempting to delve into translation, but what should make you think twice is this knowledge: failure of most projects is due to either misunderstood requirements or lack of planning.

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 several purposes:

• A roadmap for everyone involved in the project, particularly stakeholders. The project plan 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 personally like using a Linear Responsibility Chart, which is 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 specifes one or more of the following responsibilities of each stakeholder for a project deliverable: create, review, approve or not applicable.

• A metric 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 fnancial 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 dependent on several things:

• number of stakeholders, in particular team size.

• complexity of project and product.

• localization maturity of the client.

• number of deliverables.

• use of new technology.

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

Also during this planning phase, you can accomplish some parallel activities: translate the glossary, prepare translation kits, and schedule the initial client review meetings, etc.

Once you understand the requirements and have done your planning homework, you might think that it will be smooth sailing. However, the next topics highlight other reefs on which you might still shipwreck.

Slip sliding away…As a vendor project manager, you have a number of conficting objectives:

• Keep your client happy by meeting the client’s expectations in terms of deadlines, quality, and budget.

• Keep your own management happy in terms of gross margin per project and overall throughput 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, however, and you will soon meet your nemesis: scope creep. Now you’ll be facing missed deadlines, lowered margins, and general dissatisfaction from both your client and your own management.

How can you have a “can do” attitude and still keep control over the scope of your project? If you did a good job initially on defning requirements and on initial project planning, you will start your project with a well-de-fned scope. Keeping 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 changes 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, 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 fles and localized fles.

• Using a tool to manage resource allocations across all projects (for example, 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 fles, 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 review 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 fnal 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 are 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. Do this early in the project, and subsequently manage the client reviewers’ expectations.

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

Dangerous to your project are those reviewers who do not accept “corporate control” over product localization. Such reviewers will not like your localization. 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 what 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 minefeld and fnd 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, devote adequate time in defning the role of the reviewers. Your best bet in avoiding a potential minefeld is clearly defn-ing the review process and assuring the early involvement of these reviewers. If possible, include them in determining terminology and style.

In closing…Localization project management requires a very proactive “can do” attitude, combined with strong analytical skills. The complex task of localization project management is best illustrated in the diagram below.

common failure scenarios

About the author

Willem Stoeller, a certifed Project Management Professional, has been active in localization and internationalization since 1992. He has frequently taught localization topics at the Localization Institute. Willem is a VP at Welocalize, a midsize localization vendor. He can be reached at willem . stoeller @ Welocalize . com. He has been directly or indirectly involved in Project Management his entire career.

ClientSide News Magazine - www.clientsidenews.com