Localization Project Management Log

“Say, a salesman from a translation company has been after me for the last few months, and he wants some business from us. Shall we look into changing vendors?”

What’s your first answer to this question?

When I’m not in the market to change vendors and I observe that it’s not appropriate to go into the matter too deeply, I usually pull one of several quick answers out of my drawer and use it:

• “No.”
• “Sure, we can include the vendor in the next request for proposal.”
• “Forward him to me and I’ll find out more.”

I have nothing to fear by looking into a new vendor, of course, except that things that aren’t broken now, could get broken with a different vendor, and who wants to trade the devil you know for the devil you don’t know?

Last week one of my clients asked me the question about changing vendors. Sensing there was time for a little bit of education, I let her be the expert by suggesting a short true-or-false quiz:

True or False:

1. You’re convinced that your current vendor is much too expensive. (“much” is an important word here.)
2. Our engineers and your other service providers, like the Web team, cannot work with the current vendor.
3. Your in-country offices are complaining loudly about the current translation work.
4. Your customers overseas are complaining about the current translation work.
5. You hate the vendor for some other reason, and dread working with it.
6. You’re not inclined to let me to fix the problem.

I recommended that, if she scores 2 or more True, we can look into peeling off one of the languages and trying the new vendor. If she scores 1 True, we should have a chat with the current vendor and work something out.

If she scores 0 True, she is in the localization minority and should count her blessings early and often.

I also mentioned that a switch of almost any magnitude will involve a lot of re-plumbing and education. In my experience, the current vendor is charging a fair price for good, steady, reliable work, and is making my client look good (or at least, not embarrassing her). OTOH, if she really wants to make a switch, we should select a time of relatively low volume and a project/language of relatively low risk to do so.

What do you think about changing vendors? I often see problems in the chemistry with project managers. That’s an easy change to make, probably easier than most people realize. But don’t discard the vendor just because you don’t get along with the project manager; they have others, and if they want to keep your business, they’ll help you switch.

Ever hear your children make similar utterances, except with different predicates (“go to bed,” “clean my room,” “do my chores”)?

One of our clients is staffed with people too polite to say things quite so bluntly (but not too polite to dig in their heels similarly). The upside is that I enjoy working with almost everybody I’ve ever encountered there; the downside is that there are some places where their global-readiness is stuck.

Web presence
I bend over backwards to uphold a simple rule of Web navigation: Localize everything along the click-path to a visitor’s goal. So, if a visitor starts on a Russian home page, and decides she wants to download a Russian version of the trial product, I believe in ensuring that she doesn’t have to put up with English on her way through the site, unless she wants to do so. Or, if we need to push her to an English page, I try to make it apparent with “English only” next to the link.

We’ve made a lot of progress in combing out the remnants of English that dot many localized sites (that makes my skin crawl – how about you?), so that each page is linguistically pure to several levels. That was expensive and it took a lot of time.

The problem now is that this client’s site relies on a lot of plumbing for verifying that the visitor is not from an axis-of-evil country, or hacking the site, or trying to perform unsupported operations, and the UI for all of this infrastructure is in English. Much of it is just background code, but several pages (login, registration) are in English, and the infrastructure team is not interested in localizing any of it, despite my polite persistence.

License agreement
This is a hot one. When you download trial software from Germany or Finland, do you click “I accept” to a license agreement in that language? Granted, German and Finnish are not the lingua franca that English is, but how much more does it say about the relationship you want to have with your customers when you make some effort to inform them of your business terms in their language?

“We don’t translate anything legal, and it’s not hurting sales,” I keep hearing. This is a battle I know I’ll never win, so I look for victories elsewhere.

Site logic
There was a sudden need some months ago to place a terms and conditions page in the click-path to a particular download. Naturally, the terms and conditions were in English only, and I could have lived with that. The problem is that the code behind the page sent the visitor to a particular next page, without regard for where the visitor was going when he landed on the terms and conditions page.

So, visitors on the way to download the Korean/Japanese/Chinese/Spanish… version of the product sailed along the click-path in their own language until reaching the terms and conditions page. Then they agreed to text they almost certainly did not read, then they landed on a completely irrelevant page of English, with no reasonable way of getting back to their intended destination.

This is related to the inflexible plumbing I mentioned above. It’s great infrastructure; it’s just monolingual and it doesn’t really need to be.

Anyway, these bits of stubbornness amount to a small downside in a client that is not stingy about localization in general and that has a strong global presence. They’re correct when they say, “I don’t want to localize that, and you can’t make me,” so it’s easier to roll with the punches and enjoy other victories.

Besides, if I’m around long enough, they’ll move on and I can take the matter up with their successors.

What things have people told you they’re not going to localize, and you can’t make them?

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.

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.

Have you ever called time-out in the middle of a project and asked for a different project manager?

You should consider this your inalienable right as a customer.

Vendor-side project managers are, of course, people too, subject to the same grinding, erosive workplace influences that all of us are. Probably more, really, because they serve so many masters and spend a lot of their time currying favor with QA staff, translators, editors, desktop publishers and their own managers, not to mention multiple customers at a time. So if they are grumpy on the phone or unresponsive or slip deadlines occasionally – the key word is “occasionally” – it’s just part of life.

Sometimes, though, the chemistry is just not right. You’re the manager on your side and they’re your primary point of contact, and these are gears that need to mesh smoothly. How long do you want to work with somebody you don’t enjoy working with?

• The first necessity is to meet the person who will be your project manager before you award the project to the vendor. A face-to-face meeting is preferable, but if phone is the best you can do, that’s better than nothing. No sensible vendor would decline your request for this.
• Once the project is underway, teach your project manager how you want to be treated. Do you want to exchange cell phone numbers or even home phone numbers? Do you want to set up IM or Skype? Do you want weekly reports? On which day? What information do you want in them? Do you prefer to handle as much as possible via e-mail, with phone calls only when necessary? Do you want regular project status calls? The manager, to some extent, is in business to make you happy, and teaching him/her how you want to be treated as a client is a small investment in what could become a long-term relationship.
• Gauge the project manager’s competence. Beyond an introductory training session on your product, if you’re holding the manager’s hand a lot, that represents time and work you shouldn’t have to expend. Is the manager a localization newbie? Some newbies are lower-maintenance than others, and if you have to take one, that’s the kind you want.
• Most of all, is the project manager delivering on promises? Any manager has a lot of upstream influences and a change in any one of them could blow a delivery to you, but if it happens repeatedly, then you have the wrong person running your project.
• Finally, what kind of end-of-project etiquette does the manager exhibit? Is there a post-partum meeting to review how the project went? Do you just get an invoice and no handshake? Does it appear that the manager has the business sense to cultivate the relationship with you for future projects (assuming you haven’t been a bear to work with)?

If you’re losing sleep over issues like this, you need to call the account manager and suggest a change of project manager. It’s up to you whether you want to cite chapter and verse on why it’s not working out, but a simple “I need a different project manager because this one is not working out for me” will do. Any clear-thinking account manager with future commissions breathing down his neck will happily accommodate you.

What good is all the market research if your product doesn’t support the locale, and if Engineering can’t get it to support the locale?

As product manager, you’re pleased with your product’s global reach. You’ve successfully localized for the low-hanging fruit (other Latin-based character sets like Spanish, German, even Nordic), and your product and Web site makes customers happy all over the Western world. You have established robust processes for:

• researching the needs of each foreign market
• making those needs an integral part of the product requirements
• working with Engineering on timetables for support of the needs
• working with QA to ensure the engineering work can be adequately tested
• releasing in foreign markets and enjoying success in them

Now talk turns to Asian markets, and multibyte enabling of your product and Web presence. You meet with Engineering and, as they’ve done for the European languages, they assure you that their code is, or will be, clean, and that you’ll replicate in Asia the success you’ve had in Europe. Everybody nods, and it’s just like Euro-success again.

But what if it isn’t?

As product manager, you want to do your usual, excellent job of identifying market requirements and writing up the intelligence so that Engineering knows what the product needs to support. You’d better scratch a little harder, though.

1. How is Engineering going to validate the product for multibyte? Peer review of code? Bring in an internationalization engineer? Pseudo-translation? You can’t just take their word for it; you have too much at stake.
2. Can your Web team create a staging environment and test cases close enough to what the production environment will be like?
3. Has QA done a good job in flushing out bugs in your other localized products? Look back at the bug reports from German or Finnish; did they really find many problems? Did they all get fixed? Do you know for sure that they’re testing under production-caliber conditions and on production-caliber testbenches?
4. Do you really need to launch in Japanese, Korean and two versions of Chinese at the same time? Can you adopt a phased approach? Which market can give you the best support as you’re enabling your product? (Hint: It’s often Japan.)

This is the localization-equivalent of getting your ducks in a row. After you’ve done all the work of finding out what the market requires, you’d better be sure that the product you want to sell them really will perform as you claim.

Engineering, this is not business as usual. This is Asia.

Take this short True-or-False quiz:

1) You think your localization company is much too expensive.
2) Your other contractors or in-house teams cannot work with your localization company.
3) Your in-country offices are complaining about the translation.
4) Your overseas customers are complaining about the translation.

If you scored 2 or more True, you might look into peeling off a language and trying a new vendor out. If you scored 1 True, you should have a chat with your vendor and work out the problem. If you scored 0 True, you are in the localization minority and should count your blessings.

Making a vendor switch involves a lot of re-plumbing and re-education. If your vendor is charging a fair price for good, steady, reliable work, and they’re making you look good (or at least, they’re not embarrassing you), there’s plenty to be said for that.

Keep in mind also that this is a relationship. The vendor won’t necessarily get it right the first time–neither will you–but if they show improvement, and they’re willing to work with you on making things better, you have the beginning of a beautiful friendship.

You need to understand the localization process – even if you’re in denial about it – because the world is flat (apologies to Thomas L. Friedman) and the sooner you see how the process goes, the sooner you join the ever-flattening world.

Do you see your company in the following scenario?

We’re bringing a prospective new client into the flat world. Up to now, they’ve dealt with translations, in which somebody overseas says, “We need to be able to read this document in our own language.” Recently, though, the folks overseas are saying, “We need to be able to use your product in a way that makes sense to us.” The unspoken rest of the sentence, of course, goes, “…or we’ll find a different one and use it.”

They are on the road to localization. What’s next?

1. Demystify the process. What’s really involved in creating a localized product? How much will it affect this organization?
2. Identify and talk to all stakeholders. Inform them of what’s coming and what will be required of them.
3. Figure out exactly what needs to be localized: software strings, documentation, help, Web pages, installer strings, sample files, etc.
4. Create a project plan. Much of it will be wrong the first time out, but as long as you know it’s a living document, it will serve its purpose.
5. Appoint or find a project manager. The localization project needs a champion (some might say a lightning rod), because it won’t all happen on its own.

[With apologies to the sage who said, "If you meet the Buddha on the road, kill him!"]

Hope I didn’t startle you with that title, but it came to me as I asked myself how my clients would deliver localized products if I were hit by a bus, or if someone met me on the road and killed me.

The cemeteries are, as deGaulle mentioned, filled with indispensable people, which means that in time my clients would appoint somebody to pick up in the middle and finish the project. That applies to every one of the employees in every one of my clients’ companies. My replacement might even do a better job than I did, such that outside of the improvement (and the sudden drop in total irony in the building), nobody would notice the difference.

I suppose it’s a backhanded way of telling myself I do a comprehensive, one-stop-shopping job of localization project management: “Really, now: If I shuffled off the mortal coil, how would you guys get this work done?” The people who create the domestic product are accustomed to leaving all of the thought and toil to me, and they’re in a variety of departments, focused squarely on anything but the localization process. Absent the localization manager (who, in this case, has no staff), the process would probably devolve back to those individual departments. Within no time, they would have had enough and begin to clamor for a replacement.

It’s not so important to be indispensable as it is to fill in the dozens of unanticipated cracks in the process of turning domestic products into localized ones.

It’s also a good idea to keep a wary eye on people you meet on the road.