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 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:
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:
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:
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:
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:
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.
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.
News Magazine - www.clientsidenews.com
Please see some ads as well as other content from TranslationDirectory.com: