Offshoring Localization and On-shoring the Communication

You're offshoring your localization or development work to China and saving lots of money. Upper management is delighted. Your localization dollars are going further than ever. The offshore partner's project managers are professional and responsive. It's everything you'd hoped it would be.

Almost.

There's a little something that feels strange on your conference calls and status meetings. The work is getting done - mostly - and the schedules met - mostly - but there are gaps here and there in the relationship. It feels as though, when there are misunderstandings, they seem to get resolved, but not in quite the way you expect. Sometimes their approach to solving a problem seems off the mark to you, even if it works out in the long run.

In short, you feel as though the communication could somehow be better. You can't quite describe what's amiss, but it nags at you.

Believe it or not, your partners in China may have the same impression.

This week I met with one of the U.S. representatives of a large Chinese offshore development company that offers, among other services, localization. Besides finding new customers, he's tasked with acting as the on-shore presence for existing customers.

"There are subtle ways in which our managers and developers don't quite connect with some clients," he told me, "and it's not just because of the language barrier. I look at it as two layers of cultural difference: first, there's the east-west difference, then there's the cultural shift the client undergoes when product structure changes to the offshore model. In other words, it's strange enough that an outsider is now responsible for large portions of your product or service, and even stranger because that outsider is somebody with a completely different kind of life and world-view from yours."

This is a novel role. He's not the project manager, moving files back and forth and matching jobs to translators. Nor is he the account manager, working out contract details and managing payment schedules. He's the communication manager, or the relationship manager, helping to fill in the almost undefinable gaps that sometimes prevent clients from really clicking with their offshore partner. In fact, the company hired him to place his localization expertise and customer skills on this side of the Pacific, within a couple of time zones of its key clients.

"So I spend a lot of my time just listening, "he continued. "I'm on conference calls, I'm visiting client sites, and I'm getting face-time with our clients and our staff, picking up on the subtle things that we can deal with now, so that they don't blow up later on."

Whether they choose to believe it or not, most people who are offshoring work to China (and India and Romania and Lebanon and...) know that those countries will get it right sooner or later. In fact, it will take fewer years for them to get it right than it did for us to get it right.

A client-side relationship manager will play an important role in getting it right, and the position will become mainstream before long. The opportunity for both vendor and client is ripe, and the benefits are long-lasting.

If you learned something from this post, have a look this related one: "Making Sense of Outsourcing"

Making Sense out of Outsourcing Localization to China - Part 2/2

[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."

Making Sense out of Outsourcing Localization to China - Part 1

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."

Low Quotation - Four Questions to Ask

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?"

Offshored, outsourced localization blues

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:

"Only those who demand the absurd can accomplish the impossible."

Where Translation Memory Goes to Die

Have you ever heard that you're better off not going into the kitchen at your favorite restaurant? You're likely to see a number of things you'd rather not associate with a place and a group of people you like.

The same may apply to your translation memory databases. Unfortunately, you don't have the luxury of ignoring them, because things could be dying in there and costing you money.

Let's start with this sentence:

Some interfaces use "redial function/redial context" semantics instead of using IRedial to specify both.

Any TM tool could store this string and its translation without problems. Suppose, though, that the sentence (segment, in TM terms) only looks contiguous when displayed in an HTML browser, which is a very forgiving viewer, and that the source is actually broken into three pieces:

1. Some interfaces use "redial function/redial context" semantics instead of using
2. to specify both.
3.[HTML tags] IRedial.htm [closing HTML tags] IRedial

The text comes from include files written by engineers for engineers, and no line is longer than 80 characters. The tags come from the well-intentioned Tech Pubs team, which struggles to introduce some organization, hyperlinking and search capability to the product. This is pretty bruising to TM, which relies on being able to fuzzily match new occurrences to old occurrences of similar text. When the full sentence comes through the TM tool, its correspondence to the three broken fragments in TM is sharply impaired, and you (or I, in this case) pay for it.

It gets worse. If an engineer pushes words from one line to the next between versions, or if the tags are modified, the impact on match-rates is similarly impaired.

I've huddled with engineers, Tech Pubs and the localization house on this matter several times, with little progress to show for it, but here's a new twist:

We've offshored one of these projects to a vendor in China. Their solution was to re-align ALL of the English-language HTML pages from the previous version to ALL of the translated HTML pages of the previous version, effectively re-creating TM. They report about 20% higher match rates after doing this. I think this is because they're embracing the broken, dead segments in TM and finding them in the source files for the new version.

This seems like a counterintuitive approach, but who can argue with the benefits?

Offshoring and localization projects, Part IV

"We specialize in all cars, domestic and foreign."
-Sign over auto repair shop

What kind of specialization is that? Specializing in both foreign and domestic cars means, of course, that you don't really specialize in anything. Unfortunately, that also applies most of the time to offshore software development companies who have discovered that their technology clients need, among dozens of other things, localization.

I was in a meeting with a prospect last week when this came up. A project manager who has already got the religion of offshoring was pushing to award a localization project to an offshore development "partner" in China. His antagonist, a localization purist, was arguing against the award because of the partner's skimpy localization credentials. I was a fly on the wall, hoping to manage the project whichever way it went. Their respective arguments went as follows:

"We need to work with more partners in China because we can get more done for less money. I'm not worried about their lack of localization expertise, because you can put quality controls in place to make sure they deliver a good product. Every smart technology company is growing in this direction, and we need to get partner relationships in place as soon as possible."

"That country has let malamine into the pet food manufacturing process. It has put an antifreeze component into toothpaste. Its food and drug inspectors work under a conflict of interest between big pharma and the city governments that invest in big pharma. Does that inspire you with confidence?"

"Those are low-tech examples where quality problems are hard to identify. This is software, and we can keep problems like those from ruining the project. They may not get it right the first time on their own, but they're extremely adaptable and eager to keep the business no matter what. It's a relationship we should invest in."

"They're telling the world that they specialize in all cars, foreign and domestic. Look at their Web site. They're software developers, they run a data center, they write embedded software, they do datawarehousing, they run call centers and they do data entry. What else? Silk-screen t-shirts? They say they have the capability to do four dozen languages, but how many have they really done? And have they done them in our industry?"

Don't misunderstand and don't underestimate: These companies will get it right sooner or later, and it will take them less time than it took today's prominent, traditional language service providers (LSPs). They are clever, nimble and entrepreneurial enough to focus on landing the business first and then partnering with other people to figure out how to do the work second. And who could blame them? It's a simple matter of world-flattening progress.

Are you seeing these offshore companies in your projects? What do you think of the movement towards them?

Offshoring and localization projects, Part III

Here's a souvenir from one of my first offshore localization projects:

Ramesh,
We are exploring the possibility of you taking over all the localization activities from John White. Keep this confidential for now but start working on taking over in one week's time. On my part, I will forward mails as appropriate to keep you in the loop.
Thanks,
-Sunil

Sunil and Ramesh worked in the Bangalore development center of one of my former software clients. What struck me as amusing about this is that Sunil had intended to send the message to Ramesh, but sent it to me by mistake. (At least, I think it was a mistake.) This was a classic, if ham-handed, example of localization jobs and expertise (mine) going offshore with little likelihood of returning.

Once I had stopped laughing, I toyed with several potential responses.

1. Should I let them know that I knew what they were up to? Not much to gain there.
2. Should I leave the project preemptively? It was a comedy of errors anyway, but I don't like quitting.
3. Should I suddenly start billing madly to beat the axe? Not very sound ethically.

In fact, I did 4. None of the above. Instead, I went to the library and started reading "The World is Flat," by Thomas L. Friedman.

This book and its concepts are trendy and salient these days, but I got the following out of it:

Globalization and interdependence are not going to slow down for anything,
so those of us in the industry would do well
to think of localization in those terms from now on.

A few questions for you readers:

• Have you read the book?
  
• What did you get out of it that relates to localization?
  
• Most importantly, have you received your e-mail from Sunil yet?

Offshoring and localization projects, Part II

Are localization projects, jobs and expertise going offshore, never to return?

Well, frankly, those of us in the industry were offshoring long before it was fashionable. Our projects have been globally distributed, multi-time-zone, polyglot undertakings for a long time, and so the recent hue and cry (in the U.S., anyway) strikes us as inapplicable, the kind of thing that auto workers and steel unions should worry about.

Renato Beninatto of Common Sense Advisory writes, "Don and I just came back from China where we visited several LSPs and several offshore development companies. To answer your question, I wouldn't say that LSPs [language service providers] are losing work to offshore companies. Some LSPs are moving some of their back-office and testing labs offshore, and Chinese LSPs are using language services to upsell testing services. The language part of the business does not seem to have been affected. We will be publishing soon a report on our findings in China. Stay tuned."

The furor also strikes Paul Samuelson, economics writer for Newsweek Magazine, as overblown:
http://www.msnbc.msn.com/id/18699042/site/newsweek/
though for different reasons and for different industries.

Still, offshoring is beginning to feel like the new "inconvenient truth." There's no doubt that Indian and Chinese LSPs are gathering steam, and there are almost certainly instances in which prominent, traditional LSPs are losing business to them (see Part IV).

At the same time, though, the pie is getting bigger. The developing world is demanding more content and software in its own languages, and it will require more LSPs to meet that demand. "All boats rise in a high tide," I quoted eruditely to my 14-year-old son last week.

"Except for the ones with holes in them," he sagely countered.

If you're worried about your localization career-boat not rising in the incoming tide, figure out how to get the holes fixed.

Offshoring and localization projects, Part I

"Amid the seeming confusion of our mysterious world, individuals are so nicely adjusted to a system, and systems to one another and to a whole, that by stepping aside for a moment, a man exposes himself to a fearful risk of losing his place forever."

-Nathaniel Hawthorne, "Wakefield"

Not a cheery thought, perhaps, but it has some value in the discussion of offshoring in general, and of offshoring localization projects in particular.

The posts over the next two weeks will focus on the at times uneasy dance between offshoring and localization. Our goal as localization professionals is to ensure that we don't step aside for a moment and lose our place forever; rather, that we work out new ways to practice our existing expertise and learn as much as we can from the offshoring model.