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.