关于本站 联系本站 English
首页
| 登录论坛|
| 新闻 | 观点 | 本地化 | 培训 | 测试 | 招聘 | 国际化 | 知识库 | 专题 | 会员区 | 本站月报 | 关于本站 | English |
用户: 密码: 验码:  
栏目导航 网站首页>>本地化>>项目管理

失败的本地化项目案例分析
  发表日期:2008年3月31日  共浏览12665 次   出处:Clientside News    作者:Willem Stoeller  【编辑录入:giltworld
     字体颜色:    【字体:放大 正常 缩小】  【双击鼠标左键自动滚屏】 【图片上滚动鼠标滚轮变焦图片】 

  • 出处:Clientside News,2008年第2期
  • 作者:Willem Stoeller
  • 翻译:颜玉祚(北京大学计算机辅助专业)

失败的本地化项目案例分析

“你明白我的意思……”

轻率地下结论、想当然地处理事情——我们都犯过类似的毛病。而本地化项目失败的原因常常就是因为沟通不准确或不清楚,尤其是谈到交付物(你需要把HTML文件编译成一个chm文件吗?)和服务(你希望由谁来开发这个软件?)的时候。

在和客户交谈中抽取出真正的项目需求,并在项目过程中管理好客户期望,是所有本地化项目经理的重要任务。下面是一些有关项目需求的例子:

1.   中期交付物和最终交付物是什么?清晰地描述项目所有的中期交付物和最终交付物至关重要。项目交付物包括所有的产品交付物,外加项目特定的组成项,例如进度报告、缺陷报告、已完成的检查清单、翻译记忆库、术语库等等。

2.   各交付物的时间表如何?最后期限如何分类:是如你所愿的,还是很紧急的?有时候我们要处理像贸易展会这样“规定得很死的”期限,这无疑会增加项目风险。

3.    项目的预算是多少?如何处理预算差异?这是一个“依耗时和材料而定价”的项目呢,还是一个“成本固定的”项目?项目预算还应对项目变更单有一个清晰的期望。

4.    客户对最终交付物的质量期望是怎样的?在项目初始阶段建立质量标准可以极大地帮助客户设定正确的期望。对于本地化工作来说质量标准的制定不是一件容易的事,因为风格和术语的处理都囊括了太多的主观性。

5.    客户对于他/她在项目中承担的责任有何认识?我们都至少遇到过一次由于客户更新或审查源文件而无法在交付期间内完成任务的情况。客户需要理解这些延误对进度和预算的含义。应该在项目的规划阶段就确定这些期望,而不是等到这些延误成为不可更改的现实后。

 

需要沟通的不止这些。在项目执行过程中还需要沟通清楚每位团队成员需要做什么,这一点很重要。如果事先没有沟通清楚,就会导致重工、未分配的任务以及团队成员间普遍的受挫感。这让我们想到另一个话题。

缺少规划时间……

你已经把大部分时间用来谈判需求、预算以及交期。现在交易谈妥了。但是供应商和客户都希望继续项目并开始翻译活动。多数情况下,你的交付期限已经很紧了。最不愿意做的事情就是花时间做规划。立即开始投入翻译工作非常具有诱惑力,但是了解下面这点也许能帮助你三思而后行:导致多数项目失败的两大原因是:(一)误解客户需求;(二)缺少规划。

现在,是时候完成规划了,它包括项目方法、资源分配、所有中期交付物的交付期限、风险管理等等。最好做一份详细的、可以满足多种用途的项目规划:

l         作为项目相关人员(尤其是利益相关人)的指示图。项目规划将会概述项目的各阶段,并阐明各阶段内的活动和里程碑之间的依赖关系。此外,它会将所有交付物的交付期限记录在案。

l         能够清晰地描述每位利益相关者的责任。我个人喜欢使用线性职责表(LRC),这个表的左列各栏清楚地列出了所有的项目交付物,其它各列则是相关联的利益相关者。二者的交叉点上详细列出了某个项目交付物的每位利益相关人须履行的一下责任中的一项或多项:创建、审查、批注或不适用。

l         作为项目在进度、开支和质量各方面绩效的测量标准。甘特图样式的基准进度表为比较计划绩效和实际绩效提供了一种简单易行的方法。累计预算和实际成本相比较为财务绩效提供了很好的指示器。

 我听见你说:“我可没时间写一个50页的项目规划”,你说得对。项目规划的详细程度取决于很多因素:

l         利益相关人的个数,尤其是团队大小;

l         项目和产品的复杂程度;

l         客户方本地化的成熟度;

l         交付物的数量;

l         是否使用新技术;

对于多数本地化项目来说,一个考虑周详的MS Project进度表,包括资源分配、交付物描述记录、限制条件、以及所有的预算信息就足够了。

此外,在规划阶段,你可以完成一些并行的活动:例如翻译术语、准备翻译套件,为初始的客户审核会作进度规划等。

当你理解了需求并完成了规划,你或许以为前面的工作就会一帆风顺了。然而,在接下来的话题中,我们就会谈到其它一些可能让你船沉大海的暗礁。

失误偷偷潜入……

作为一个本地化供应商的项目经理,你有很多相互矛盾的目标:

l         在交付期限、质量和预算方面达到客户的期望,让客户高兴;

l         在每个项目的毛利和所有项目的产出方面,又要让自己公司的管理层高兴;

让客户高兴的最容易办法就是接受任何以及所有的项目变更——面带微笑,摆出一副“我们可以做到”的态度。然而,照这个逻辑推理下去,你很快会受到惩罚:项目范围蔓延。结果是你要面对“错过的交付期限”、“降低的毛利”、“来自你的客户以及你自己公司管理层的不满”。

怎样才能在保持一个“我们可以做到”的态度的同时还控制好项目的范围呢?如果你的需求定义得很好,初始项目规划也做得很好,那么你的项目至少在开始的时候是有一个明确的范围的。但是,控制住这个初始范围需要有正式的审批流程——任何对原项目范围的变更都需要审批;不这样做的结果只能是自尝失败苦果。

本地化项目的范围控制包括:

l         在立项阶段和规划阶段,详细讨论如何通过项目变更单来管理变更。

l         对于每一次范围变更,应及时地生成一个项目变更单。这里关键是要及时:范围变更的需求一提出,而不是等到项目结束。

l         对每一个项目变更单进行沟通、讨论、和审批,基于它对项目目标的影响(进度、预算、功能和质量)。

l         使用版本控制软件和翻译记忆库来跟踪源文件和本地化后的文件版本。

l         使用工具(例如,MS Project Server)来管理各个项目的资源分配,帮助你获取项目变更对你自己的项目和其它项目的影响。

最常见的范围变更包含更新源文件、增加区域,增加交付物。在有些情况下,最好把变更请求当场一个新的项目,而不是更改项目变更单,特别是这个请求包含新的交付物的时候。

有一条很好的规则,值得牢记心中,即:项目范围应该包含达到项目目标必须的每件事,但是不包含不必须的任何事。

审校员:伪装的叛徒?

我们最后的失败原因是本地化项目所特有的:客户方审校员的角色,以及他们对项目的潜在影响。对于多数本地化项目,最后一个项目里程碑是客户正式接受产品交付物。一般每个产品的本地化版本会有一位或多位的审校员。

与软件开发项目不同,由于自然语言的本质,本地化和翻译项目的质量要求比较主观。尤其是术语和风格,大多由客户审校员的偏好来决定。

正确地抓住客户方审校员认同的术语和风格需求至关重要。在项目早期的时候就这样做,之后则对客户审校员的期望进行管理。

在项目规划阶段,你需要确认客户方审校员是谁。你应该和他们建立互信关系。通常情况下,和你打交道的是一位背上审校责任并以此为主要任务的国内销售人员或营销人员。

有些审校员在产品本地化上不接受“公司控制”,这对你的项目是个极大的危险。这类审校员不会喜欢你的本地化产品。他们对英文原版没有发言权,而他们又觉得自己的市场需要超过公司管理层愿意支付的更大程度上的区域适应。这种情况特别容易出现在(线上或线下的)营销和培训资料。作为一位本地化项目经理,你也许发现自己闯进了一个公司雷区,而本地化质量则成为客户公司各部门之间争夺控制权的武器。

想要从这种失败情况中恢复过来,非常困难。因此,在规划阶段,应投入足够的时间来定义审校员的角色。避免潜在雷区的最好办法就是:清晰地定义审校过程并保证审校员的尽早参与。如有可能,在决定术语和风格的时候也将他们包含在内。

最后……

本地化项目管理需要一种非常积极的“我们可以做到”的态度,以及很强的分析能力。本地化项目管理的复杂任务在下面这幅图中得到了很好的阐述。

关于作者

Willem Stoeller,注册PMPProject Management Professional),从1992年开始活跃于本地化和国际化行业。他经常在 Localization Institute公司讲授本地化相关的课题。他是一家中等规模的本地化供应商Welocalize公司的副总裁。您可以通过这个地址联系他:willem.stoeller@Welocalize.com。在他的职业生涯中直接或间接地参与到了项目管理中。

 

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.


上一篇:知识管理在本地化业务中的应用
下一篇:翻译价格:翻译和本地化公司的成本

 相关专题:

·专题1信息无

·专题2信息无
 
  热门文章:
 · 2007年全球翻译公司25 [37645]
 · 缺陷管理工具Bugzill [33099]
 · “本地化世界网”介绍 [30406]
 · 使用Trados翻译XML [26950]
 
 相关文章:

·没有相关文章

相关评论:(评论内容只代表网友观点,与本站立场无关!)
相关评论无
发表、查看更多关于该信息的评论 将本信息发给好友 打印本页
关于本站 | 网站历程 | 使用声明 | 网站地图 | 联系本站 |
本地化世界网版权所有,版权所有2003-2008
京ICP备05035404号
网站统计:    论坛统计:
页面执行时间:226.563毫秒