Getting along with your (vendor-side) Project Manager

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.

Localization on the Cheap - Get Students to Do It

Maybe you read this and became encouraged to have your products and Web pages translated over the Internet by college students in other countries:

"In April and May 2007, Palex held an English translation contest for Microsoft software and documentation. It is the second translation contest organized by the company with the purpose of stimulating interest in translation and freelance work and selecting new full-time and freelance employees. With more than a hundred applications submitted, over 70 participants - most of them students and young professionals - completed the off-site translation assignment. Those who delivered the 20 best translations participated in the final stage.

"For the final assignment, the competitors had to translate an HTML page and correct 11 localization errors in a dialog box. Although translation quality was of the highest priority, the technical background of the participants - such as the ability to handle HTML correctly and the number of localization errors found - earned additional points.

"Andrey Cherkovsky, a freelance translator, was selected the winner. The second prize was awarded to Sergey Plotnikov, a chief specialist at Tomsk Regional Energy Commission, and Rostislav Romanovsky, a third-year student at the Chemical & Chemistry Engineering Department at Tomsk Polytechnic University. Neither has ever been a professional translator. Mark Lesun, a newcomer to freelance translation, ranked third. [emphasis mine]"

So, they got lucky. Don't forget, though, that out of 70, only 20 qualified as "good," and out of those 20, only 3 took prizes, and one of them was already a freelance translator. Can you find the 3 out of 70 that won't embarrass you?

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.

Market Requirements for Localization

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.