Acceptance criteria for Localization

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.

User Interface and localization

"We are Marketing. We own the user interface."

An engineer with one of my clients told me, with some bitterness, that a previous regime had summarized its hegemony over the company's software product with those two sentences. I'll grant you that it sometimes help in a company to know which lines are not to be stepped over, but I'll also grant you that you catch more flies with honey than with vinegar.

Most of us don't mind if Marketing dictates the user interface, unless people with our global perspective tell them that something in the UI won't work well when the product is localized and they refuse to accept it.

In this case, the fuss is over an HTML-based UI and help system that lives in firmware in a networking device. The old Marketing guard wanted a tabbed look with labels on the tabs (Connections, Security, Setup, Help, etc.), and the tabs had to be graphics. The graphics are .gifs, nobody knows where the source files are, and we're trying to find an expeditious way to localize the product, including the text on those tabs. (If you're in localization and haven't already faced this situation, I can assure you that you don't have long to wait.)

I've floated some ideas by them that might result in a more flexible approach for future versions of the product. The current Marketing team is not so doctrinaire as their predecessors, but they're not very engaged in this process, either. I offered Ockham's razor: Let's remove the tabs and replace them with hyperlinked text near the top of the page, and the problem will go away. They have yet to reply to that.

I'll give them another week, then make my own arrangements. After all, "We are Localization. We own the rest of the world."

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

Is your new localization vendor working out?

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.