Localization Management: One Big Bag, or Several Smaller Ones?

Are you getting to the point where you need to consider decentralizing your localization project management efforts? That decision point usually comes with growth (more languages, more products, shorter lag-times). Here are some things to consider in distributed vs. centralized localization management models:

• Trying to plant and cultivate this expertise in each group (QA, product teams, release engineering, sustaining engineering) is pretty tough. One prospect appeared to manage things in a decentralized manner like this, telling me that "the car drives itself," but I have my doubts. I've never seen any organization that did it well and robustly without a lightning rod or "localization czar" that ran around pestering people company-wide.
• Frankly, I think decentralization is difficult because, for all but the largest, best funded firms, it's just plain hard to find and keep that many individuals interested in driving international products. I suppose it could be built into the company's incentive structure, so that managers understood it was part of their charter to localize, but that wouldn't guarantee that they would actually care about it, and caring is at the heart of long-term localization management.
• Until somebody really cares about it, most internationalization/localization projects have an out-of-band feel to them. It takes a long time before they feel familiar, and the sooner everybody knows that there's somebody (besides them) responsible for putting out the Japanese version of the product or Web site, the sooner everybody can get back to work.

For these reasons - and a few others - I counsel companies to dedicate a single project manager , preferably with domain expertise, to as many localization projects as practical, rather than to expect each project manager to handle the localization aspects of his/her own projects.

That model will last a good while in most companies.

The Localization Manager's Team - If You're Lucky

How many of you out there in L10n-Blog land get support from other internal groups?

A long time ago my boss told me why it's important to be a complete zealot about localization, especially in an organization that is new to the process.

"For people in general and engineers in particular," he observed, "localization is interesting only once: The first time. After that, they're just humoring you."

I've kept that in mind as I take off like a street fighter with most clients, eager to ride the wave of novelty that accompanies the prospect of going global. Product managers brief me up one side and down the other, in-country partners promise to devote legions of in-house staff to testing the product the minute it's ready, and QA resources jump at the chance to configure localized test benches.

At the water-cooler level, employees want to connect me with their cousins who are studying French and would love to proofread the manuals, or with their former co-workers in Japan who would make excellent beta testers. Naturally, I diplomatically avoid these golden opportunities, but I appreciate how high spirits can run at the outset.

In time, though, product managers stop returning phone calls, in-country partners run out of time, and QA leads are unexpectedly besieged by other priorities. (In one memorable instance, after I had explained to the QA manager the relatively paltry need for a few machines and 10 person-hours of testing per week for 4 weeks, she replied, "Oh, we'll have no part of that," and walked away.)

It's not so tiresome when my task is simply to get a localized product out the door; in that case, I work things out on my own to achieve that goal, since I know the process from end to end. But if clients hire me to build teams and to put procedures in place for localization, the expectation is different, and people know it's an edict from above. I need stick and carrot for engagements like that. That's more like a, well, a job.