Localization Project Management Log

Is it really localization if you’re not changing the language?

Obviously, the answer is “yes.” Automakers localize their products by placing the steering wheel on the left or right, yet everything remains in English.

So it is with a marketing campaign. A client is launching a campaign in several English-speaking countries: USA, UK, Canada, Australia, even Hong Kong. Nobody consulted me on the campaign – why would they when translation is not involved? – but I heard about it through the grapevine and weighed in.

This is a localization issue. Even though the other locales all use English, we are, in effect, translating content for them.

Mind you, it’s not the kind of localization effort that calls for translation memory and engineering, but there is a big QA lesson from localization that I’ve tried to impress on the team: We need to run the campaign past a stakeholder in each country during this process.

If it’s worth going after customers in the other locales, it’s worth researching terminology, spelling and suitability to get it right, and part of that is in-country review.

“Do NOT try to get this right yourself,” I’ve told the marketing team. “No matter how much research you do, you’ll miss something that an in-country local would spot in a heartbeat.”

What do you do differently for English-to-English (or French-to-French, Spanish-to-Spanish, etc.) localization?

How are you getting through this recession? Assuming you can keep your own body and soul together, can you keep your localization program from slipping into a coma?

A few anecdotes from recent conversations and transactions:

• A fellow L10n project manager complained over lunch about slashed budgets and an increasingly impatient boss on the other side of the planet. Fortunately, he takes some kind of pleasure in figuring out how to do more with less, but some mornings he spends the commute time wishing he could relocate tomorrow without turning his back on his mortgage, benefits and (frozen) salary.
• All that budget-slashing and money-saving today means you’re resuscitating a feeble program in two years, when things pick back up. We’ve managed a pick-up-the-pieces project like that, and spent most of our time combing network storage for archives, glossaries, TMs and any other forgotten assets. What a mess.
• The operations director at a language provider told me what she’s seen every time there’s a downturn: “Our clients lay off the people who know what they’re doing in localization, and all sorts of expertise goes up in smoke. Then, underlings without a clue about the subject jump (or get thrown into) the breach to maintain the programs, and our project managers spend a lot of time educating. They’re used to doing that for normal attrition, but when suddenly a large percentage of our clients need hand-holding, projects really slow down.
• We submitted a proposal in January that was orally accepted in February and approved for requisition two weeks ago. When the client showed me the chain of approvals for the requisition, I thought it was solid enough to start work, so I did. Two days ago a purchasing agent with the client’s company sent me e-mail, calmly expecting a 7% reduction on the project total. Stay tuned.

With my other hat – marketing – I look for the silver lining, the opportunity in all of this. One of my clients plays the card of positioning yourself as best you can for the day when things recover, so you can leave your competitors envious and gasping in the dust. But how can you do that without spending big money?

Invest in your relationships: Take engineers and product managers out to lunch. Let them cry on your shoulder, then once they’ve calmed down, let them know what you do for a living. This is a good time to open up the black box of localization and gently explain the voodoo you do.

And stop reading the business section of the newspaper (if your town still has one). I’ll tell you when it’s safe to read it again.

Most people don’t understand localization. We can use this to our advantage.

Last week I had a kickoff meeting with a new client to manage their localization project. From previous discussions with them I had a pretty clear idea of how to start the project, what I would need from other people (engineers, QA team, in-country reviewers), and what was still unknown to all of us.

I did what any sensible project manager would do before a meeting: I wrote up an agenda.

It knocked their socks off.

“Wow! Who wrote this up?” asked the program manager.

“You’ve thought about this a lot more than we have,” admitted the product manager and engineering lead.

I merely smiled, pleased to see that they were pleased, but secretly wondering whether I’d made it look too easy. “Probably not,” I told myself. “This is the black magic for which they’ve hired me. They’re paying for this level of service and forethought.”

So, what did I put into the agenda that inspired this praise, and how can you do the same?

1. Process Overview. Assume that you’ll be working with smart, engineering-grounded, methodical people on the project, so spell out a smart, engineering-grounded method of localizing anything in general and their product in particular. They want to see the plan, and poke and prod at it a bit.
2. Who’s Doing What? Most of the time, of course, you’re going to be the main – maybe only – lightning rod on the project, but you can’t do everything. Tell Engineering at which point in the project you’ll need new builds and how much of their time you think it will take. Let QA know how the project will affect them and which test suites they’ll need to modify. Ask upper management or sales to choose  in-country contacts who can review glossaries and help find beta testers. Make sure everybody knows you plan to be the anchor on the project.
3. Open Questions. What don’t you know yet? Ask about resource freezes, file formats, weekly meetings, logins for offsite testers, schedules, and what status reports they expect of you. Most of all, talk about expected release dates for the localized versions; they’re almost certainly unrealistic, so the sooner you burst that bubble, the better.

If you take your colleagues by (pleasant) surprise early on, you can publish your high expectations for how the entire project will go.

You’re a localization project manager. What makes you any different from other localization project managers?

Marketing people devote careers to answering this question, and because they’re in Marketing and we don’t know what they do, we assume that it doesn’t apply to us. But stop and think about your next salary review, and come up with a few things to mention to your boss that make you different from other project managers:

• Are you learning new technologies that the company will care about in the near future?
• Are you specializing in projects, customers or terminology of strategic value to the company?
• Can you point to a sum of money you’ve saved the company by doing something new?
• Have you asked your clients to recommend you on LinkedIn, so that you can show your profile to your boss? (What could be easier than that?) (You are on LinkedIn, aren’t you?)
• Do you have an idea of what you want to do beyond managing localization projects, and have you discussed it with your boss?

These help you formulate your unique value proposition (UVP), as those inscrutable people in Marketing call it; the combination of talents and drive that makes you different. If you’re not different – or are different, but you don’t show it – you’ll stay where you are. If you’re different – and show it – you’ll stand out in your boss’ mind.

Common Sense Advisory has posted a Quick Take for its subscribers called “The Makings of an Innovative LSP.” They look at every vendor’s eternal quest for something above commodity status and describe the characteristics of vendors who have succeeded in differentiating themselves from their competitors.

This company-level perspective applies to those of us in the trenches as well. Are you learning another language? Have you taken a class to learn sales techniques to close more business? Do you have the skills to train incoming project managers? Are you learning about search engine marketing or other ways to generate leads? Can you put together a paper and present it at ATA?

Start working on your UVP. And see whether your marketing manager knows what that stands for.

Things are quiet on our localization front at the moment.

The nature of managing localization projects as a consultant is that, if there’s work to do, I do it. If there isn’t, I go into down-time mode and focus on interim activities like these:

• Analyzing return-on-investment. This is, in part, how I eventually grew into the role of international product manager. My quest for data on the language-by-language profitability of our localized products takes me to more far-flung corners of the company than I’d anticipated, and it isn’t always embraced by everybody in the organization, but I learn a lot. The Accounting department has some vague numbers on revenue from localized products – the overseas sales offices have more accurate data – but it’s hard to allocate costs accurately because a localized product costs more than just the amount paid for translation, and companies treat this differently.
• Evangelizing. I spend some time getting my ducks in a row with Engineering, Marketing and Production, “educating” them on what goes into a localization project and how much more internationalization we can afford for the next version. I work at keeping people’s eyes on the goal of simultaneous shipment (“sim-ship”).
• Working things out with the vendors. Some projects merit a post-mortem – which I have always preferred to label “post-partum” – meeting to review what went well and what needs to go differently in the future. It’s common for some action items to come out of such a meeting, and so I often spend time with the vendor putting process improvements in place for the next round.
• Tinkering with the machine. Every project brings up several internationalization issues (embedded strings, rogue controls, bits of unruly not-invented-here software), so I take advantage of down-time to find out how to deal with them, then pleasantly surprise the engineers with the research I’ve done.
• Finding beta testers. It’s helpful to spend time in between projects mining our registration lists for new beta testers for the localized versions. I find new prospects, weed out the people who haven’t helped on the previous round of testing and – very important – handily reward those testers that have stepped up and done a good job for me.
• Talking to the Sales teams. The salespeople in the overseas offices know best what sells and what local customers think of the products, and down-time is an opportune moment to collect formal and informal data and requirements from them.

What about you? Do you ever have down-time between localization projects? How do you spend it? Post a comment and let us know.

 

It Helps to Have a Buddy
In the RipStik How-to-Ride video, the narrator recommends having a friend help you steady yourself when first you mount. This I would gladly have done, but my sons and nephews were too busy laughing at how ridiculous I looked to stop and help me.

Talk to localization professionals in other companies about their experience in simship. If you don’t know any, find some on LinkedIn, or lob a question about simship into Multilingual Communications (see “Blogos” link to the right). Don’t rely on your vendor for this; they’re in the back seat and you’re the one behind the wheel.

You Won’t Truly Know Whether Your Organization Is Up To It Until You Commit
I have no idea what possessed me to ask my nephew whether I could try his RipStik, but as I stood over it wondering how to operate it, I realized it wasn’t going to reveal its secrets until I’d made the first move…and the second and the third and so on.

You may be able to gauge your company’s commitment to simship by asking people, but you don’t know whether the process is truly possible until you’ve been through it. You, as localization manager, will of course shoulder most of the burden, but there are plenty of things you’ll need from other people, and only by doing it can you see how close to or far from the goal you’ve landed.

Quantify Your Goals
I challenged myself to get to the corner and back on the RipStik, but I forgot to specify the amount of time I was willing to spend on it. Not much of a goal.

When you launch the project, specify “simultaneous:” source plus 15 days, source plus 30 days, same day for source plus two languages then 30 days for the remaining languages, etc. It makes success appear more probable to all of the other players whose support you’ll need.

So, hop onto your RipStik and give simship a try, but keep in mind one important dissimilarity between these two endeavors: I’ve realized that, like many activities that involve balance, it’s best if you keep your head up and focus on your progress, but not on how you’re making your progress. In simship, that’s a luxury reserved for upper management. You need to keep tabs on everything all the time.

Have you said this lately? Have you thought it lately? Do you wish you’d joined the Rolling Stones when they invited you?

What do you plan to do after localization? What will you do next in your career?

Look at the localization people around you. How did they get into this business? How has their job changed since they did what you’re now doing? At least two prominent figures in our industry started out as professionals (attorney and tax consultant), then started small translation companies that grew very large. Neither of them translates anything or manages projects anymore, but both have used the industry as a springboard to broader career paths.

On the vendor-side, translators become project managers, who become leads, who become salespeople, who ultimately run the company, or start their own. On the client-side, localization managers become product managers, who become directors of product marketing. On either side, your company could easily be purchased and you might have to start over from scratch. Will you be ready?

I’ve visited high school and college classes to describe to language students how they can use their talents to enter several industries, including translation/localization. It hasn’t occurred to me to address the question, “After that, what?”

Of course, you don’t need to wait until you’ve grown tired of localization to start planning your own outplay. If you don’t have another marketable talent in your back pocket right now, then you must not be reading the newspapers. Years ago I had a very discerning boss who asked me in confidence, “In how many completely different ways can you earn a living? You should always be accumulating multiple talents you could apply to make money, if you had to.”

So, during the day you’re a localization manager, and at night you offer bookkeeping services to small businesses. Or, Monday through Friday you run translation projects, and on Saturdays you do search engine optimization for friends’ Web sites.

Yes, it’s more work, but when the localization train reaches the last station and you get off (or are pushed off), you’ll have more options in picking the train to board next.

“All of the strings are embedded in the code.”

There was a time when I welcomed – or at least was not very much surprised by – sentences like this one. They came from engineers in response to my questions about the readiness of their software strings to be localized. Strings embedded in code, of course, are more or less inaccessible to localization techniques, since nobody wants to hand off an entire code base to a translator, and no translator wants to wade through an entire code base trying to find strings to translate.

So, when one of my client’s engineers said it to me yesterday in reference to an application in a larger product we plan to localize, I briefly welcomed it. It means more work.

But then I realized that combing all of the strings out of the code and into separate, accessible files will require a great deal of time and effort (not mine). Engineers don’t usually enjoy working on this kind of task, so it will fall to the bottom of the priority stack, and the product manager won’t go to bat for it, and so this particular application will stick out like a sore thumb as a non-localized component in an otherwise localized product suite.

“Is there a phased approach we could take to enabling this app for localization?” the engineer asked.

I appreciated his attempt to save the game, but a partially localized product is rather ugly. We could enable and translate the menu and dialog strings for this release, and go back for the error messages in the next release, but the mongrel product is not very appealing to users in the meantime.

This is disappointing, because we’ve made such long localization-strides elsewhere in the product suite, and dealing with this newly acquired app feels like such a giant leap backwards. I guess I’ll work up some estimates on the time required to enable the application, then make my case to the product manager and development lead to generate some interest and start the process from the beginning.

Isn’t that why we localization project managers and international product managers were sent here?

What do you do in your company when engineers tell you that all the strings are embedded in the code?

In 1999 I created a presentation on minimizing the risk in localization projects. It offered several scenarios with possible decision-paths and ways to keep risk low. I’ve dusted off the presentation and offer a sample from it today.

1. Your company decides to localize its product, and assigns the project to the Technical Publications Manager. Unfortunately, that is you. Do you:

• rebel, because it’s not why you hired on?
• rebel, because it’s not a Tech Pubs function?
• rebel, and do it anyway?

The Risk – Entrusting the project to someone who doesn’t want it or cannot manage projects. To minimize the risk, pick someone with project management expertise over linguistic/writing/engineering/product expertise.

2. Your CEO tells you he wants to localize into 5 Western languages and 2 Asian languages first time out. He offers you an extra 5,000 stock options if you complete the project successfully. Do you:

• say, “Piece of cake!” and take the challenge?
• ask, “Am I being set up for failure?”
• counter, “I’ll do that if you do the press tours”?

The Risk – Biting off more than you can chew, especially the first time out. To minimize the risk,
schedule a scaled-down “pilot project” rather than picking a fight you may not win.

3. You explain to your QA Manager that she will soon have the opportunity to test French and Portuguese versions of the product. She replies, “Oh, we’ll have no part of that.” Do you:

• laugh?
• cry?
• pretend you didn’t hear her and say, “Right. I’m glad we understand each other”?

The Risk – Intimidating or alienating co-workers with the localization process. To minimize this risk, educate first, then start mustering resources. Also effective is an evangelization effort to boost your project’s visibility everywhere in the organization.

In short, it’s not very exciting to go home at the end of the day and tell your spouse that you spent most of your day minimizing localization risk, but it is quite important. The risk lives in lots of narrow corners, and it’s your job to find it before it finds you.

Sooner or later, someone may ask you, “We’ve got a new release coming up. Why don’t you give us a presentation on what you’ll need to localize it properly?”

After you’ve recovered from the shock, will you have a ready answer?

I received this request last week from one client, and turned it into an invitation to present at the regular meeting for all of the leads – software, Web, documentation, project management, QA, release – and some people in upper management. It’s meant to be a very brief (10-15 minutes) presentation, which felt like a limitation at first, but which now strikes me as an advantage because it will help me focus better.

They’ve stapled me to a slide presentation, and I made the most of it.

• Slide 1: Hello! I’m the Localization Guy and I live to pester people. (Maybe I don’t say it in quite that manner…)
• Slide 2: Scope of Work – These are the software, Web and documentation bits we’ll need to localize, and the parts that are already in TM.
• Slide 3: Timing of Work – Let’s hand off anything we can as soon as it’s stable, even if the localized releases aren’t for several months yet.
• Slide 4: Help Wanted – Here are areas of the project outside of my control, where a little localization-mindfulness will save some time, money and headaches. This includes tagging XML files for text that should not be translated, handing me early software builds for internationalization testing, and thinking about the stable files we can hand off ahead of product release.

I think this will suit their desire for information. They don’t want to know the details of how I do what I do, but I want them to know what I need from them.

You too should have a presentation like this in your desk drawer or on your hard drive. Just in case they ask.