 |
 |
 |
 |
|
|
Home | More Articles | Join as a Member! | Post Your Job - Free! | All Translation Agencies | |
|
|||||||
|
|
|
|
Can You Translate PMI-Speak?
Does your next localization project involve working with a PMP (Project Management Professional) or with someone from a PMO (Project Management Office)? If so, you just might need some translation help for project management-speak. Many language service providers are adopting or adapting the Project Management Institute’s approach to localization. Inevitably, jargon comes with that approach, and with any new jargon there is a risk of miscommunication. Here are three of the most common and important terms you will hear from those using the PMBOK (PMI’s Project Management Book of Knowledge) as their roadmap for project management work. This guide will help get you through the next PMI-driven localization project. Stakeholders The PMBOK defines stakeholders as: “Individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or project completion. They may also exert influence over the project’s objectives and outcomes.” You might hear “stakeholders” used in the following: “Have we identified all the stakeholders in this project?” Another way of saying this is: “Have we left anybody out?” Is there a customer, a manager, a team member, an influencer, a functional group that may, just may, delay or derail the project at some point? Experienced project managers know how dangerous it is to assume everyone is on board and seated with their seatbelts fastened for the remainder of the project. Experienced project managers create the list of project stakeholders early on, and maintain their involvement in the project. Localization projects present special challenges in this regard, since “stakeholders” may be geographically dispersed, linguistically diverse, and organizationally distant from the localization vendor manager. In-country review is one area where delays often crop up due to stakeholder expectations. Too often in-country review, which should be used by local stakeholders to validate key terminology choices and other locale-specific elements, dissolves into lengthy debates on such matters as local versus central control of the translated texts. Examples of project failures due to misaligned stakeholder expectations abound. In an extreme case, one in-country reviewer insisted on rewriting all of the product documentation from scratch in the target language, causing missed ship dates and leading to an impossible task of reconciling translation memory. Both vendor and client-side project managers can avoid this kind of problem by diligently seeking out all stakeholders and addressing this kind of fundamental disagreement in advance. Managing Scope PMBOK calls managing scope: “The sum of the products, services, and results to be provided as a project.” In other words, the scope of the project is all the work, and only the work, you will do as part of the project. Once the scope of a project is defined, and especially if a contractual agreement is in place, then project scope must be tirelessly monitored and controlled since whenever the scope of a project changes, i.e., the amount of work committed to changes, the cost and time of a project will also change. Since changes to cost and time are typically undesirable, experienced project managers use various tools and tricks to keep scope change, or “scope creep,” to an absolute minimum. You might hear the term “scope change control” used in response to a proposed alteration: “I’m sorry, but we’ll need to put that through the project’s scope change control process.” Typically, that means, “We are going to assess the impact of this proposed change on the project, and then someone in authority will have to sign off on all of it before we move forward.” As with software development and other types of projects, “scope creep” can be “external” (arising from a customer request) or “internal” (generated by the vendor project team itself). Customer-initiated changes in scope can be addressed through open communications. Internal “scope creep” often arises from incomplete analysis or documentation of the source files. For instance, when translatable text is included in code fragments within an XML document where none was expected, this can affect the total word count dramatically. It will be much easier to resolve this sort of problem without a domino effect of project delays if there is a well-established approach to scope management. The use of freelance translators who are far removed from the project’s business decisions can also cause internal “scope creep.” The translator may have strong opinions about the quality or style of previously translated segments in the TM or the terminology choices that have been used in previous versions. This is especially true when there is a transition underway from a decentralized “in-house” localization approach to a centralized and outsourced approach. Even if the linguistic comments are justified, it is important to consider many other factors, including release schedule, localization budget, and even the impact on the existing customer base, which may have become comfortable with the current terminology, however flawed. Again, a cooperative approach to scope management is the key to resolving this type of situation effectively. For instance, it may be appropriate to plan and budget for a full linguistic review as part of a future release, thus protecting the committed ship date of the current version. Project life cycle Project life cycle, per PMBOK, is: “A collection of generally sequential project phases whose name and number are determined by the control needs of the organization or organizations involved in the project. A life cycle can be documented with a methodology.” Some organizations also attach “phase gates” to a project life cycle, in which case the work completed through a certain phase must be approved before the project can move forward. In-country review is often considered a “phase gate.” A “project life cycle” is simply a way of sequencing and grouping all the tasks to be completed to finish a project. In this approach, a project is composed of phases with names like “Initiation,” “Development” (often replaced with “Translation” for localization projects), “Testing,” and “Closing.” This can be very helpful for planning and reporting, but if applied too woodenly, it can also serve as the proverbial square hole into which you must fit a round peg. For example, it sometimes happens that software localization testing efforts will reveal problems with the software itself or with the approach to internationalization. Addressing these problems may require looping back to previous phases, potentially even all the way to “Initiation,” as the client considers the implications of various approaches. If an organization has adopted a standard project life cycle for all its projects, it is because they hope to reduce the amount of variation in the way projects are planned. This approach helps in scheduling oft-forgotten tasks that typically belong to the “Initiation” and “Closing” phases. Carefully defining scope, stakeholder expectations, communications plans, etc., during project initiation can prevent unpleasant surprises later. Similarly, the project closure phase can include such tasks as reconciling original estimates with actuals, conducting stakeholder satisfaction surveys, documenting lessons learned and other tasks which can contribute to stronger vendor-client relationships, and ongoing process improvement. We hope this helps you understand these three pervasive PMI terms and tools and, even more important, equips you to communicate and work more effectively within a traditional project management framework for your next localization project. Chris Morgan, MBA, Certified Project Management Professional (PMP) and Certified ScrumMaster, was most recently the PMO Communications Specialist for Temple-Inlands PMO and responsible for designing and streamlining the PMO's processes and tools. She is passionate about innovative, people friendly, and results-oriented approaches to project work. Bob Donaldson has served as the VP of Strategy at McElroy Translation since January, 2007. His role includes providing strategic direction to McElroy’s technology adoption plan and also developing a global network of partners, enabling scale while maintaining the essentials of the company’s customer-centric culture. He has 25 years of executive experience in software development, international business development, project management and technology strategy consulting. An academic background in Slavic Linguistics and early career work as a Russian translator give him insights into technology challenges arising in the language services environment. Published - August 2008
E-mail this article to your colleague! Need more translation jobs? Click here! Translation agencies are welcome to register here - Free! Freelance translators are welcome to register here - Free! |
|
|
|
|
|
|
| |||
Legal Disclaimer Site Map |
Does
your next localization project involve working with a PMP
(Project Management Professional) or with someone from a
PMO (Project Management Office)? If so, you just might need
some translation help for project management-speak.
