Main | Versão em português| Versión en español
A Day in The Life of a GPM

In this interview, readers will learn more about the activities, best practices and career of Ccaps’ most recent staff member, Cassius Figueiredo.

Project Management: Art or Discipline?

Consultant and professor André Barcaui explains how to balance two apparently contradictory qualities when managing projects.

The Hub of the Wheel
Willem Stoeller

Do you have what it takes to be always at such center?


What really is localization project management? First, some concepts. Let’s look at a formal and somewhat dry definition of localization project management.

“Localization is the process of adapting and manufacturing a product so that it has the look and feel of a nationally manufactured piece of goods. Thus, localization is the piece of the global business puzzle that enables companies to do business in markets outside of their home market.” (The Localization Primer, LISA)

“A project is a temporary endeavor undertaken to achieve a particular aim. Projects differ from operations in that operations are ongoing and repetitive while projects are temporary and unique.” (Project Management Institute, ©2002)

When we put it all together, localization project management is the application of knowledge, skills, tools and techniques to localization project activities in order to meet project requirements.

Now let’s look at a more dynamic view. The accompanying graphic shows the localization project manager (LPM) as the hub of the localization wheel.

How did localization project management evolve over time? Initially, LPMs were mainly expediters and file movers. They worked in a pre-planned environment, and their entire focus was moving files to be localized from the client through translation, editing and desktop publishing and back to the client. Projects were small; they required few, serial localization activities and used well-understood, simple technology. A good example would be the translation of a small manual. The activities are mainly to translate, edit, correct layout and review. These are all serial activities with no overlap.

Larger, more complex (many parallel threads) projects using advanced technology, such as found in many software localization projects, forced the LPM to become more of a scheduler and tracker of progress. Upfront planning and day-to-day control of the projects became essential, and many an LPM developed a hate/love relationship with Microsoft Project. A typical software localization project has graphical user interface and message localization and testing, help localization, documentation localization and often marketing collateral localization. Many of the localization activities for these four components take place in parallel with many dependencies among them. For example, screenshots for the manual can only be taken once the sample data has been localized and once the software has been localized and tested.

These capabilities of planning and tracking are no longer enough to be an outstanding LPM in today’s economic environment. The complexity of many localization projects (large corporate Web sites with interactive components, multitier enterprise applications, e-learning content and so on) and additional job pressures — such as poorly understood or shifting localization requirements, the need for simultaneous shipment (simship) of the localized product, the focus on return on localization investment and finally a very competitive environment — force the LPM to be foremost a communicator.

Extracting through dialog the true localization requirements from the client, managing client expectations over the course of the project, moderating the client review process and assisting the client in determining the return on localization investments are now common activities for many LPMs.

For large, complex projects the LPM needs mainly a set of analytical project management techniques and strong communication skills. In particular, to be an outstanding professional, the LPM needs to be able to create and maintain energy in the project team and to foster creativity among the team members. In other words, a good LPM needs to be a coach to a team. Often these qualities are overlooked, and the focus tends to be on the analytical techniques. The latter are essential but not sufficient. Without the communication and coaching skills, a project will never be an outstanding one.

Let’s return to the LPM as the hub of the localization wheel and see when and where each of the five major activities comes into play. We will do that in the context of a localization project management model.

Localization project management activities and phases include the following:

The Statement of Work (SOW) Formulation phase provides project stakeholders with a clear understanding of what needs to be done in terms of requirements, constraints and assumptions and the project objectives. In the typical client-vendor relationship, the SOW is the proposal from the vendor written in response to a Request for Proposal by the client. The main focus here is on what needs to be done — the scope of work.

The Project Approval phase is the official starting point of the localization project with a committed contract. This phase also provides the LPM with the authorization to start the project. In the client-vendor relationship, this is the point in time when the proposal becomes a contractual agreement to perform certain localization services.

The Project Initiation phase provides information on how to do the project, when the project can be completed and how much the project will require in terms of resources and costs. During this phase, final resource assignments are made for the project team. This is the planning phase of the life cycle where a detailed roadmap is developed for the project. For too many localization projects, this phase is minimized in order to start the localization activities sooner. Invariably the latter approach reduces substantially the probability that the project will produce the agreed upon deliverables on time, within budget and with the expected quality.

The Project Execution phase is where the bulk of the localization activities take place. Often, we tend to focus on this phase to the detriment of the first two phases that are more important to the success of the project.

The Project Control phase provides quality control for project deliverables, as well as control over project scope, progress and budget. As indicated, this phase is executed in parallel with the Project Execution phase. Additionally this is also the phase where the LPM moderates the client review of intermediate and final deliverables. The latter is specific to localization projects since it deals with the subjective notion of translation quality (in particular, the issue of linguistic style).

The final phase, Project Closure, formalizes the acceptance of the project results by the customer. A second very important objective of this phase is to discuss and document the lessons learned so that future projects go more smoothly. This is typically done in the context of a post-project meeting with all stakeholders in attendance. These lessons learned are the LPM’s weapon to insure continuous improvement on his or her localization projects.

Within this entire Localization Project Management model, we can identify a number of critical success factors that are also reflected in the “hub” diagram. The next section will discuss these critical success factors in more detail.

The various phases included in the localization project management process

What are these localization project management critical success factors? The first critical success factor is agreement among stakeholders regarding project requirements. Stakeholders include the project team, the boss, the client and the project sponsor (the person who provides the funds, authorizes the project and empowers a person as the project manager). Here are some examples of project requirements:

What are the intermediate and final deliverables? A clear description of all intermediate and final project deliverables is crucial. Project deliverables include all product deliverables, plus project-specific items such as progress reports, defect reports, completed checklists and so on.

What is the timetable for all deliverables? How are the deadlines classified (desired, critical and so on)? What is the budget for the project? How are variances handled? Is this a “time and materials project” or a firm, fixed-cost one? What are the customer expectations for quality of the final deliverables? Establishing quality criteria at the beginning of a project helps greatly in setting the right expectations. Quality criteria should be defined by type of defect for each final product deliverable. What are customer expectations in terms of his or her responsibilities on the project?

Often, the negotiation over project requirements is seen as too time consuming, and the “let’s start translating” attitude prevails. However, neglecting to invest the necessary time upfront to clearly outline project objectives will prevent you from meeting customer expectations, and thus set you up for failure.

The second critical success factor is to develop a detailed project plan that can serve as a roadmap for everyone involved, that is, the stakeholders, in the project. It will outline project phases; indicate how activities and milestones within the phases are dependent on each other; and document the deadlines for project deliverables.

A clear description of each stakeholder’s responsibilities is best achieved with a Linear Responsibility Chart (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 against which to measure project performance in terms of progress, money spent and quality is necessary. A baseline schedule in the Gantt chart format supplies a simple way to compare planned versus actual performance. Cumulative budget versus actual cost comparisons provide good indicators of financial performance.

The third critical success factor is managing stakeholders’ expectations through ongoing communication. Never, ever forget that a very large component of project management is formal and informal communication.

The fourth critical success factor is controlling the scope of your project (that old fiend known as scope creep). You need a formal procedure for approving any change to the original scope of the project. Not doing so is setting yourself up for failure yet again.

The fifth critical success factor is obtaining management support by aligning product localization with corporate objectives and by communicating with management in terms that the latter can understand, such as how localization directly increases shareholder value. For many LPMs, this is extremely difficult to achieve because more often than not they do not share a common language with management. All requests or arguments brought forward by many LPMs need to be backed up by solid metrics in order to be taken seriously by management.

The sixth and final critical success factor is very specific to localization and translation projects: capturing correctly the terminology and style requirements as seen by the client’s reviewers and subsequently managing those client reviewers’ expectations. This is so critical because, unlike software development projects, localization and translation projects have very subjective quality requirements due to the nature of natural language.

Localization project management is a dynamic profession within a changing industry. The rest of this article looks closely at three often-asked questions regarding localization project management: Should localization project management be outsourced? Is localization project management a critical factor in vendor selection? Is localization project management a billable service?


As we shall see in this section, the important question is “What localization project management services should be outsourced”? If the answer is yes, then it should also be a critical factor in localization vendor selection, and it should be a billable service due to its importance to the success of the project. To answer these three related questions, let’s first look at the added value that a localization vendor provides.

The localization vendor provides, through localization project management, planning, process, resource management/procurement and progress tracking/control to the various services needed in a localization project — translation/editing; layout; localization engineering and translation memory management; quality control and testing. Additionally, the localization vendor often provides localization and internationalization consulting and training. The LPM provides at least in part these latter services.

Second, let’s look at the true localization buyer needs. These needs depend on four related factors: the localization maturity of the buyer; the buyer’s infrastructure to support localization; the complexity of products to be localized; and the services outsourced.

Localization maturity of the buyer. On the one end of the localization maturity scale, we find the buyer who is still very new to localization and who does not have repeatable localization processes (procurement, creation of localization kits, vendor support, review processes and localization project management) to rely on. Additionally, this type of buyer often has products that are not fully operable, conforming to standards and regulations, and localizable in the planned target markets (internationalization).

On the other end of the scale, there is the buyer who has considerable localization experience and has mature, repeatable processes in place. This buyer typically has products that are well internationalized, and any exceptions are known and well understood.

Buyer’s infrastructure to support localization. Buyers at the low end of the localization maturity scale usually do not have full-time localization staff, and the localization function is often less than optimally placed within the organization. Buyers at the high end of the maturity scale typically have full-time localization staff reporting into product development. The recent economic downturn and resulting reorganizations and staff reductions have introduced a wrinkle in this localization maturity and supporting infrastructure relationship. Many buyers with medium localization maturity now find themselves with little infrastructure to support localization.

Complexity of products to be localized. The complexity of the products to be localized determines how much localization project management is needed. For example, a Flash tutorial with audio and animation is more complex to localize than a FrameMaker-based manual; a multitier enterprise application is often more complex to localize than a standalone desktop application; and a highly interactive Web site is more difficult to localize than one with limited interactivity. The product complexity is directly related to the number of various services and resources needed to localize the product.

Services outsourced. On the low end of the outsourcing scale is the buyer who outsources only raw translation. On the high end of the scale is the buyer looking for a turnkey model with essentially all services outsourced.

Putting It All Together
All buyers who meet one of the three profiles in the accompanying table need to outsource a substantial portion of localization project management activities. Therefore, these buyers should make localization project management one of the top criteria for vendor selection. Thus, if localization project management is one of the most important services you obtain from a localization vendor, expect to pay for these services as a separate billable line item.

Reprinted from MultiLingual magazine (2004, #63 Volume 15 Issue 3) with permission from Multilingual Computing, Inc., 
Willem Stoeller is a certified project management professional and a vice-president at Welocalize.
Main | Versão em português| Versión en español