Why do l10n projects fail?

-common failure scenarios for localization projects

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 files 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 Lo­calization Project Managers. Some examples of project requirements are:

Ÿ           What are the intermediate and final deliverables?  A  clear description of all intermediate and final proj­ect deliverables is crucial.  Project deliverables include all product deliverables, plus project-spe­cific items such as progress reports, defect reports, completed checklists, translation memories, glos­saries, etc.

Ÿ           What is the timetable for all deliverables?  How are the deadlines classified: desired, critical?  Some­times we are dealing with “hard” deadlines such as Tradeshows which increase project risk.

Ÿ           What is the budget for the project?  How are vari­ances handled?  Is this a “time and materials” proj­ect or a firm, fixed-cost project?  This should also cover setting clear expectations about change or­ders.

Ÿ           What are the customer expectations for quality in the final deliverables?  Establishing quality crite­ria at the beginning of a project helps greatly in setting the right expectations.  Quality criteria are difficult 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 cli­ent failed to meet delivery deadlines for source up­dates or reviews.  The client needs to understand the schedule and budget implications of those de­lays.  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 top­ic...

No time to plan…You have spent substantial time ne­gotiating requirements, budgets, and deadlines. Now the deal is closed.  Both  vendor  and  client want to get on with the project and start the translation activi­ties. 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 proj­ect approach, resource allocations, deadlines for all in­termediate 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, par­•  ticularly 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 dead­lines for all project deliverables.

Ÿ           A clear description of each stakeholder’s responsi­• bilities. I personally like using a Linear Responsi­bility 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 specifies 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 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 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 Proj­ect schedule, complete with resource assignments, with notes describing deliverables, constraints, and all bud­getary 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 conflicting objectives:

Ÿ           Keep your client happy by meeting the client’s expectations in terms of deadlines, quality, and bud­get.

Ÿ           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 ac­cept any and all changes—with a smile and “can do” at­titude. 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 gen­eral 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 defining requirements and on initial proj­ect planning, you will start your project with a well-de­fined scope. Keeping this scope under control requires a formal procedure for approving any change to the origi­nal 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 files and localized files.

Ÿ           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 files, additional locales, and additional deliver­ables. 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 proj­ect objectives and nothing else.

The reviewer: a rebel in disguise? 

Our last failure scenario is unique to localization proj­ects: The role of client reviewers and their potential im­pact 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, ter­minology and style are subjective and are mostly deter­mined 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 identified. 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 particu­lar 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, devote adequate time in defining the role of the reviewers. Your best bet in avoiding a potential minefield is clearly defin­ing the review process and assuring the early involvement of these reviewers. If possible, include them in determin­ing 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.

About the author

Willem Stoeller, a certified Project Management Profes­sional, has been ac­tive 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 ven­dor. He can be reached at willem.stoeller@Welocalize.com. He has been directly or indirectly involved in Proj­ect Management his entire career.