Localization Project Management Log

[Continuation of last week's post, Part 1]

Since it was my charter to make this offshored localization project work, we built checkpoints into the project to detect problems as soon as they arose.

We scheduled bite-sized chunks of translation, engineering, layout and editing work early in the project, then handed them off for review in our client’s in-country offices. We established twice-per-week conference calls with the vendor’s team to reinforce the decisions we made in e-mail threads. To overcome low TM matches and shorten the project schedule, we sent source and target files from previous projects for realignment in TM. We agreed mutually on a format for weekly reports that would highlight project status without becoming onerous. In short, we followed every prescription for a successful localization project, and we followed them more carefully than normal.

Our client’s Korean office has expressed satisfaction with the final product. The decision-makers, pleased that nothing went awry – at least, nothing that required their intervention or remorse – asked for a post-partum on the project, in which I underscored these points:

· It was a pleasure dealing with the vendor. They were prompt, courteous, efficient and unequivocally determined to making us happy.

· Even with the short time allowed for the project, they brought to our attention errors in the source materials and they addressed what they considered pre-existing translation issues.

· Their end of the conference calls was noisy to the point of distracting. Several of them in a meeting room with poor acoustics talking into a cheap speakerphone made for frustrating encounters twice a week, regardless of whose bridge we used. The project succeeded in spite of it, but it struck me as a poor choice of places to save money.

· It became apparent that they were cutting corners in ways that experienced LSPs don’t bother trying to cut them (rogue copy of TM software; use of a shareware help compiler on a project that depended on features unique to RoboHelp; testing on Windows MUI instead of native localized OS). I can overlook some things like this, but I’d rather not have to.

Our client had already localized this product into Korean over several versions for a number of years, qualifying it as a sustaining effort. Vendors in China and India have done a brisk business in sustaining engineering, especially for large IT companies with legacy code bases. Naturally, they are turning the corner towards new product engineering, which, like localizing a product for the first time, demands more of the relationship between client and vendor.

Recommendation: If your team is sufficiently aware of what it takes to localize your product, and has a history of successful localization, then testing the waters with a Chinese or Indian vendor in 2008 should be among your options. If your organization is new to localization or must entrust the process to someone who is, this might prove rash. In no event, however, should you simply find the lowest price, lob your product over the partition and hope for the best.

If you enjoyed this post, please read the related article, “Offshoring and localization projects, Part I.”

If you have not yet tested the waters of offshore LSPs, consider making 2008 the year in which you take the plunge. You know you are going to do it sooner or later, and if you don’t, your successor will, so you may as well learn the lesson for yourself.

In 2007, one of our clients embarked on a localization project with a Chinese vendor. This brought me, in my role as consulting localization project manager on the client’s side, onto the leading edge of the project. Misgivings? Yes, I had a few:

· The company had no visible qualifications as a localization vendor, though they had devoted lots of Web space and marketing to testing, data analysis, application development, sustaining engineering, payroll processing, helpdesk and data mining. How can you be very good at anything when you specialize in everything?

· Against the same request for proposal, the company’s bid on the project was about 25% lower than that of two other Western LSPs. It didn’t help that they misread the RFP and omitted a big chunk of work, but even if they’d included it, they would still have been 15-20% below the other vendors. What kind of quality would we get for a price that low?

· The target language was Korean, not Chinese, which meant that, as low a price per word as they were offering me, some vendor in Korea was almost certainly offering them an even lower one. What caliber of linguistic talent could we expect?

· Our client imposed a project deadline bordering on the preposterous, which annihilated precious time I wanted the vendor to devote to editing and QA. Midway through the project the deadline changed to allow some more time, but it had already introduced a great deal of stress.

· The lingua franca of the project was English (because I don’t speak Chinese). While the vendor’s efforts were valiant, their English was weak, and I foresaw this as a problem even before we had awarded the project.

· Replete as the Western news media were in 2007 with recalls on Chinese toothpaste, toys, cots, tires, medicine, pet food and other products, it was easy to tar this company/industry with the same brush and worry about their level of quality assurance.

Despite these carefully articulated misgivings, our client’s decision-makers had already made up their mind (and corporate direction) to award the project to the Chinese vendor. So, since it was my charter to make it work, we built checkpoints into the project to detect problems as soon as they arose.

I’ll describe these checkpoints and the upshot of the project in next week’s post.

If you enjoyed this post, please read the related article, “Offshoring and localization projects, Part I.”

Have you figured out how to add value, even when you don’t get the job?

A client asked us to look into quotations on taking some marketing materials in MS Word and Adobe InDesign into Traditional Chinese. Our preliminary word count was around 15,000 total, and we spent time educating the client on how to deal with all of the graphics that had embedded text. Since they were marketing materials for an upcoming trade show, we put on our best neckties and helped the client think through the project as far as possible.

As we were preparing to analyze the files for a proper quotation and statement of work, I received this message:

“I wanted to let you know our Taiwan office has located a local translator that has quoted us $1800 for this job. Do you think your quote will be a lot higher? If so, there’s no need for you to proceed. Just didn’t want you to spin your wheels.”

We suspected our quotation would be 3-4 times higher than that. What would you do? Would you:

1. Doggedly pursue the business, refusing as a matter of principle to be low-balled?
2. Upbraid the prospect for falling for such a low price?
3. Do nothing, considering it beneath your dignity to reply?

You’d have good reasons for any of these responses, I suppose. I gave it a good, long think over last weekend and replied Monday:

“That is quite low. If price is your paramount criterion, then you’d better go with that quote. In any event, you should make sure it includes:

• second set of eyes (besides those of your in-country reviewer)
• translation memory
• glossary (terminology list)
• desktop publishing + PDFs

Let me know how it goes.”

We in the industry stand to gain nothing by scaring prospects, but since power in the Web 2.0 age seems to come from a delicate balance between giving everything away and keeping your families fed, perhaps our real value-add lies in helping prospects ask the right questions.

Your thoughts?

If you’ve enjoyed this article, you might like another one I wrote called “Why Are You Charging Me For That?”

The experienced project manager with your localization/translation vendor approaches a new client/project by asking you, “Has this ever been translated before?” Her big goal is to discover whether there’s a translation memory database floating around, to help her translators do their work more quickly and keep your costs low, and her background goal is to find existing documents with key terms already translated and approved.

Smart companies maintain these key terms in a “glossary” or terminology list. Glossaries are far less comprehensive than translation memory because they serve a slightly different purpose: Instead of proposing a fuzzy-match translation for an entire sentence, they serve as a reference for the translators. Good translators know how to find translations for generally accepted terms like “closed-loop servomechanism” and “high-definition multimedia interface,” but if the sales manager in your Shanghai office has already told you how he likes to see the word translated, everybody will be happier if that preference is observed.

So where do your glossaries live?

“Live” is the important word, because glossaries change and grow with time. Most glossaries I’ve seen are in a spreadsheet or word processing document. While that’s better than nothing, it can suffer from decentralization, since updates don’t always make it to everybody involved in the project, and some translators run the risk of using old terminology.

One of my more localization-savvy clients makes its glossary available on its partner portal, requiring a login and password. The php-based application, which is actually hosted by a translation vendor, allows searching in multiple languages. My client deliberately does not make the glossary available for download or export; this ensures that everybody is using the same version with all updates.

I like this model. The assets reside on the client/owner’s site, and the terminology “lives” with the linguistic experts, who can easily modify it. It’s a bit more work for the translator, who would rather have a flat-file document, but overall it serves linguistic interests well. It’s tried-and-true technology built in to most computer-aided translation tools.

What are you doing with your glossaries?

Do you have manuals, resource files, help projects or entire Web sites that you’ve been localizing for several years and through several versions? Have you thought about the “permafrost” in those files; i.e., the sentences, paragraphs, pages and chapters that haven’t changed in ages?

Are you being charged for them in your localization efforts?

In my experience, vendor pricing includes discounts for segments (usually entire sentences or bits of text surrounded by paragraph markers) with high match rates to text that has already been translated. So, a new 30-word sentence at $.25/word may cost $7.50, but a 30-word sentence that does not change at all from one version to the next may cost $.03/word, or $.75.

But why are you charging me for that?

Vendors have different rationales (and they are welcome to post them here) which often boil down to the necessity to “touch” the words in one way or the other: either in engineering unchanged paragraphs into the new manual, or in translation memory maintenance, or in the human editing pass when eyes land upon them. These words are the spare tire of localization, in that they haven’t changed, but they’re still along for the ride, and moving their weight requires some modicum of additional gasoline.

As a localization manager, try explaining that to your boss.

So, if I don’t want them to charge me for the words, or for any words that don’t require translation, what should I do?

• Perform your own triage. Pull out code samples, for instance, which will never need to be translated, and hand them to your vendor in a text file. Ask that they be aligned to themselves in TM so that the words fall out as 100% matched. The translators won’t touch them and you won’t (shouldn’t) be charged for them.
• Move to a CMS. Deploying a content management system is a long-haul solution; but if this is a long-haul problem for you, look into it. With a CMS in place and an interface between your vendor and the system, it becomes easier for you and your vendor to separate matched from non-matched segments. That which is easier, should cost less.
• Give instructions, not words. If you suspect that there have been only a few changes to a 40-page manual, use a diffing tool to find them, write up the changes, and hand them off to the vendor with instructions to charge you hourly for the spot-changes. If the vendor knows exactly what to change where, it eliminates the guess work, the TM analysis, the file preparation and the engineering. This lowers your costs of localizing the book.

You should be able to have a calm discussion with your vendor about these jillions of unchanging words, and arrive at one or more methods for eliminating unnecessary work. Try to go beyond “Why are you charging me for that?” to “What can we do so that you don’t have to charge me for that?”

Interested in this topic? You might enjoy another article I’ve written called “Why are you charging me for that? – Part 1“

Have you ever asked your localization vendor this question? Or, if you’re a vendor, has any client ever asked it of you?

For a few clients, we manage large documentation projects, notably HTML Help and Robohelp localization. When the vendor translated 800 HTML pages for version 1.0 of the product, a particular client swallowed hard and paid for all non-matches, because it was the first time localizing the product.

By version 2.0, the Help had grown to 1400 pages. Many of the original 800 pages had no translatable changes, but Trados dutifully scooped up all of those words, dropped them into the “100%” or “95-99%” buckets, and the vendor charged us for them, even if at a greatly discounted rate.

“Why are you charging me for that?” I asked. I’ll have more on this topic in an upcoming post, but for now:

If you’re on the vendor-side, do you have a good answer for that question? If you’re on the client-side, have you ever received an answer to that question that satisfied you?

Have you ever gone to the extent of developing acceptance criteria for a localization vendor’s deliverables? Beyond that, have you ever sent a vendor an acceptance letter summarizing these criteria, and grading the vendor on each point?

After years of my simple handshake-and-phone-call approach to acceptance, one of my enterprise clients asked me to develop and communicate these criteria formally. It didn’t require too much effort, since I knew what I had liked and disliked about the vendor’s performance all along. Here are the points I drafted:

PERFORMANCE

• Responsiveness: You attended all conference calls and apprised me in a timely manner if you were unable to attend. You responded to e-mail very quickly.
• Delays, schedule: You reported only a couple of delays on the project, none of which was more than two workdays in length. In the main, you maintained your schedule day to day and week to week.
• Weekly reports: Your weekly reports were punctual and informative. They helped me to communicate accurately the status of the project to other members of the team at BigCorp.
• Issues, questions: Your process for moving the translators’ questions and my answers back and forth was simple but adequate.

TRANSLATION

• Quality: Preliminary reports show that our customers were satisfied by the translation work.
• Bug fixes: You incorporated feedback from the reviewers and me as we requested.

DELIVERABLES

• On-time delivery: You delivered all files to us in a timely manner. You delivered the final files 2-4 calendar days ahead of the final deadline.
• Project files: After giving us the main deliverables on time, you performed housekeeping on the supporting files and delivered them to us.

Frankly, I left out a few things, like the fact that conference calls were arduous because of their phone system, and the rather attention-getting directory that appeared on our FTP site one morning labeled “Trados_crack”. But the point of the message is to convey acceptance, and it serves that purpose well.

Did I leave anything out? Let me know.

I don’t quite need to eat crow over this, but let’s put spin on it and say that I’m happy to be proved wrong.

Three months ago a new client insisted on pushing a Korean project to a one-stop-shopping Chinese offshore development house that does everything from running datacenters to debugging your Javascript. “We need to explore new partners,” they told me. “Besides, they can do the work for much less money.”

I raised the usual gamut of concerns, from the vendor’s lack of linguistic credentials to the project manager’s English skills, but I knew my client had already made up his mind, and just wanted me to nod and make it work. And, as I blogged a few weeks ago, I have no doubt that the offshore houses in China, India and elsewhere in the e-developing world will figure out how to make this model work after initial glitches. After all, we here in the West did.

Just to spice things up, my client leaned on the Chinese vendor to deliver about two weeks sooner than I thought prudent. I don’t know why he insisted on this; there was no promise-date to our Korean customer, and I thought it was a recipe for slapdash QA and diminished translation quality. Nevertheless, the vendor agreed, and began logging weekend hours to meet the deadline.

The upshot of the project is that the vendor handed off final deliverables about 3 days ahead of the already ridiculous deadline. I am impressed, the client is pleased, the vendor’s project manager is still recuperating, and everyone seems to have gotten what s/he wanted. The vendor was very responsive throughout the project, knowing full well that this was a litmus test for bigger projects to come. Our in-country reviewer claims that the translation is on par with previous Korean translation (read: We’re not crazy about it, but we’ll put up with it), which is an important criterion.

This vendor is part of a very large Chinese company, and that probably helped. They could marshal resources and expertise from elsewhere in the firm to meet the demands of this project. A smaller vendor might not have had that advantage, so this strikes me as an important point in evaluating an offshore vendor.

The experience reinforces my First Law of Project Management:

Changing localization vendors can be stressful. It’s an entire “getting to know you” process you would rather avoid, but sometimes you have no choice. Like having wisdom teeth removed.

Here are some points for evaluating the fit of your new vendor.

On the downside:

1. Are there truncated strings in the software they send you? They should have reviewed these and should not send you software with such an easy problem to resolve.
2. Do they speak and write good English? Conference calls with people who don’t (or won’t) speak English are frustrating and unproductive.
3. Are there any “oops” moments early in the project? One new vendor focused on my detailed description of the changes in a document, and assumed that they were the only difference in the new version. They had overlooked 8,000 words in new files I had handed off in the localization kit. Oops.
4. Are you customers (internal or external) satisfied with the quality of the translation from the new vendor? If not, you need to address this in a hurry. I pointedly asked our Korean office what they thought of the quality of the new translations compared to the old, and they replied, “The quality seems to be about the same as before.” Perhaps a bit less than eloquent praise, but it was important for me to know.

On the upside:

1. Are they finding mistakes in the original English version and sending them to you? Sometimes these take the form of “This sentence seems corrupted, please explain.” If you have the bandwidth and patience for it, you’ll see that these are actually prefabricated bug reports that cost you almost nothing to submit, with the benefit of improving your product (especially the documentation, which is where most such problems lie).
2. Are they helping you think about long-term improvements to your international product process? Vendors are in a position to suggest internationalization (I18n) techniques for your product that will prevent you from maintaining several code bases, for example. Does the new vendor have the perspective and degree of experience to tell you, “You know, if you make each of the control labels the size of your largest language, you can use the same dimensions universally, and we don’t have to charge you so much for resizing them each time.”
3. Are they cleaning up pre-existing messes? Old messes die hard, and you can be sure that your translation memory databases have plenty of them. A new vendor comes to them with a fresh perspective and can help you clean them up, especially if it helps them to do their work better.

The more experience you have with new vendors, the bigger your own list of evaluation points will be. The sooner you deal with them, the less trouble your project will be for you and for the vendor.

Like wisdom teeth.

What is your most frequently used Web search regarding localization? Are there search phrases you check every now and again to see what new results they yield?

Over the last couple of years, I’ve tuned the keywords on this blog and on our Web site, www.1-for-all.com, for both pay-per-click and search engine optimization. I have a pretty good idea of which search topics bring people to this blog, and here are the top five topics, with my comments:

1. Localization of HTML help projects (Robohelp, CHM, etc.). I can’t tell whether people have trouble with this, or whether they’re poking around to find out whether they are going to have trouble with it once they undertake it. My hunch is that Robohelp, the dominant product for creating HTML help, either doesn’t do a good job creating localized help systems or doesn’t do a good job in explaining how to create them. Our experience has been that double-byte localization requires a specifically enabled, separate version of Robohelp, which strikes me as silly, but perhaps Adobe has addressed this by now.
2. How much to charge/pay for translation. Everybody wants to know this. Responding to the frequency of these queries, I wrote an article called “Going Global Without Going Broke” to help people who want a few benchmark figures from which to cobble together a budget. If you’re any further along than that, you should just contact a vendor, push your files to him and get an estimate. If you’re a translator or want to become one, phone a localization company, tell them what you can do and find out what they’ll pay you.
3. Localization project manager/management. I would guess that about half of these are vendors (a.k.a localization service providers, or LSPs) and half are companies with localization needs to fill.
4. Localization jobs. Most of these queries come from Ireland. There’s a relatively high concentration of localization talent in that country, and perhaps a high rate of turnover as well.
5. What is localization? Again, the frequency of these queries prompted me to write articles called “Opening the Black Box.” I’m glad to see people asking this question, because it demonstrates continuing and continuing interest in this specialty. At the same time, however, I notice that some of these queries come from China and India, suggesting to me that the IT shop which has just promised you it can localize your software for one-seventh the price you’ve gotten from other vendors, is now trying to figure out what’s involved in fulfilling that promise.

At the other end of this list are the searches we’re not seeing: questions we believe people should be asking but aren’t.