“How long will this project take?”

It’s the classic question in localization. Everyone wants to know how fast they can get something localized. Once someone decides they need localization, speed is everything.

If you ask any localization professional how they measure delivery speed, chances are you’ll hear something about translation turnaround time (TAT). This is a standard metric in the industry that determines how long a localization project takes. Usually, it’s measured from the point files are handed off until the time they are delivered back in their localized form.

Turn-around time is basically a process duration metric. It can be used to measure vendor delivery speed from point of handoff to an agency from a buyer organization, or sometimes from the point of internal handoff until internal delivery.

Note: turn-around time is usually something that is used for localization projects with human translators involved, even ones that rely on machine translation post-editing. For pure machine translation processes with no human involvement, turn-around time is not usually a metric that anyone cares about, since processes can happen near-instantly.

But to me, turn-around time is a deficient metric, for a number of reasons.

In this article, I’ll share how localization turnaround time is typically used. I’ll cover a few common ways you can actually speed up localization, and then explain why turnaround time is not a great metric to focus on. Then I’ll introduce a new metric, average project duration, and explain why I find this to be far more helpful in the context of a high-growth, fast-paced, digital company.

Using Project Size to Predict Turnaround Time

Asking a localization pro, “How long does localization take?” is like asking a web developer, “How long does it take to build a web page?” It depends on what you want on the page… and a lot of other factors. Same is true for localization.

If you search really hard online for answers to how long localization takes, you might find a basic general guide, one that most of us in the industry don’t like to use, but end up forced to lean on, in some form or another, for planning purposes. This general guide leans on size. Using size to predict duration is somewhat like estimating a website project timeframe based on the number of site pages. It won’t be totally accurate, but it can provide some general direction.

Here are the classic groupings:

• Small projects (500-5,000 words). Because a translator can deliver 1,500 to 2,500 words per day (depending on language and content), this size of a project will take around 2 days. You can add more translators to a project, of course, but in general, the more linguists on your project, the greater the risk of an inconsistent or suboptimal user experience.
• Medium projects (5,000-10,000 words). Generally, the guidance here is that this type of project will take around 7 days of work, enabling time for not just translation, but review. If time allows, you might even get the benefit of some terminology management software baked in.
• Large projects (10,000 or more). This is a grey area. It’s not that a project of 10,000 words will take 7 days and thus a project of 20,000 will take 14. It really depends on many factors. But in general, allowing about a week for every 10,000 words is not a bad idea. It might just take longer depending on the content type, file formats, and so on.

This type of guideline gives requesters some sort of framework to go off of, but for most of them, it won’t be reassuring. If anything, it will actually be more frustrating to learn that localization can take this long.

Ways to Decrease Turnaround Time

There are many great ways to ensure that turnaround time for localization projects is shortened to the bare minimum. Unforunately, most of them are things that fall outside of the realm of the localization team’s control. They are not quick and easy fixes either:

• Ensure ease of transfer between systems. Content can be transferred easily from a content management system (CMS) to translation management system (TMS) and back. This removes manual human steps and speeds things up exponentially.
• Create a logical content structure. Content is highly organized (tagged, labeled, consistent file formats, etc). This makes it easier and faster to find things, get them out and into translation systems, and back into the right place.
• Implement source content version control. If the content to be localized is going to be updated frequently, one of the most important things to account for is version control. This will enable updates to be detected quickly, so that localized versions can be updated just as seamlessly.
• Introduce globally-minded authoring. If the team creating the source content isn’t very globally-minded, this can cause many challenges when it’s time to localize. Files might be overly Anglo-centric, or full of examples or baked-in images that can’t be easily localized. Worse yet is when minimal leeway given to the localization team to actually adapt them. The more the team that creates the content has localization in mind from the start, the better.
• Make it easy to share context. The more context the linguists have who are working on a localization project, the faster and easier localization will be. Giving the translators and reviewers a clear sense of where the translation appears, in what context, and how the user will rely on it to make a choice or complete an action, is the holy grail! Note: “Context” can sound fluffy, but all it really means is that your translators can clearly see and understand the intent of the message they are translating at any given point, to ensure a great user experience.

Turnaround Time Largely Depends on What Happens Upstream

What’s the problem with using turnaround time (TAT) as a metric for localization?

Well, as you can see, the biggest things you can do to decrease localization turnaround time, listed above, are not fully controlled by any localization team at any company that I’m aware of. There is usually a tangled web of people responsible for content systems and processes at any company, and the bigger a company gets, the harder it becomes to untangle the content knots. You could try to institute things like “content governance,” which sounds great to a localization person, but to many stakeholders, will invoke fears of slowing them down or decreasing their autonomy. It sounds to them like premature optimization, or merely overcomplicating stuff. In reality, it just means doing things in a very organized and structured way to minimize human involvement and speed things up.

The best a localization team can do is influence, engage, and enable their stakeholders to heighten their awareness of these issues, to prevent the “garbage in, garbage out” scenario from happening. The more the upstream stakeholders learn about the connection between the way they create content and the bottlenecks they inadvertently create for localization, the better. Only then can they enable the process to become more efficient, which means… faster!

The DOWNSIDe of Leaning Too Heavily on Turnaround Time

So, what happens when we place inflated importance on turnaround time? Here are three very common consequences:

1. Agencies add more translators to your project to meet the deadline / improve TAT. This leads to poor quality and a worse end user experience in the languages you’ve localized into. No one will be happy with this outcome, except the person who is keeping an eye on TAT, for reasons no one really understands.
2. Agencies ask translators to work longer hours. This may burn them out. They might get sick of your company, and start rejecting projects that have such horrendous deadlines. No one wants to work for a “boss” like that. You also don’t want your company to start getting a reputation as one that sends out projects that translators dislike due to source quality issues. The best translators won’t work on this stuff. They are usually paid by the word, so they can simply earn more money doing projects with better source content that has less friction involved.
3. Agencies begin to train and onboard more translators for the long term. This is the more sophisticated solution that solves for the longer term — and probably the least likely to happen. Will you be able to keep them busy with projects in a sustained and consistent way? And, do you even have a style guide and training materials to ensure proper linguist onboarding? If not, there is no point in really doing this. In fact, most agencies won’t bother to go this route unless you can guarantee higher volumes. There is no financial incentive for them otherwise.

None of these things actually get at the root of the problem. The best of the solutions is #3, but for that, I would argue that turnaround time is still not the right metric. Instead, a capacity metric (how much capacity can we handle at our necessary quality levels?) would be better-suited for the purpose that turnaround time purports to solve.

So, this leads me to ask a question. Isn’t it kind of ridiculous for localization people to use a metric like turn-around time to measure their own performance, when there are a huge number of variables outside of their control affecting that very metric? Why, as an industry, do we fall into such a trap? Why do we not measure the parts that we want to actually draw attention to, and that really need improvement, instead?

Introducing Average Project Duration

How can we create a new metric that will take us beyond turnaround time? Break out your projects into different phases, making sure to include ones that depend on your stakeholders and the things that need to be fixed upstream. This will help you drive better conversations with stakeholders. In turn, this drives process improvement and what you ultimately want, speed!

Basically, average project duration breaks your localization projects into phases that are meaningful for your team and company. Tally up the time in each phase in order to get a total duration. Take the average across all projects to determine the trends and areas that need improvement.

The phases we currently use are as follows:

• New project request
• Scoping
• Awaiting assets / specs
• In queue
• Linguistic sign-off
• In localization
• Closed

These are examples of phases that are derived from our typical production processes, which is somewhat unusual as it comes from a hybrid model with an internal team. Not every team would need the same exact stages.

Look at the Percentages of Time Spent in Each Project Phase

What this enables you to see is where there are bottlenecks in the process. For example, let’s say your breakdown across phases for projects with humans in the loop typically looks like this:

• New project request – 10%
• Scoping – 30%
• Awaiting assets / specs – 20%
• In queue – 5%
• Linguistic sign-off – 5%
• In localization – 30%
• Closed – N/A

To me, a perfect view of this would be that the maximum time is spent in localization, and all the other parts of the process happen seamlessly. In reality, we can see in this example that 30% of the time is spent in scoping and 20% is in awaiting assets / specs. Why are those parts eating up 50% of the total project duration?

Upon further investigation, it might be that scoping is taking too long because assets were not final, or changes were being made on the source side, or source files were not accessible in an automated way. Perhaps in awaiting assets, it was taking the content creators too long to figure out if in fact they even had the final versions of their files ready to go.

What would an ideal breakdown look like? It depends on the company, the type of project, and the attributes of projects, but perhaps it might look something like this:

• New project request – 1%
• Scoping – 5%
• Awaiting assets / specs – 2%
• In queue – 1%
• Linguistic sign-off – 1%
• In localization – 90%
• Closed – N/A

The higher the percentage of time spent in localization as opposed to the other phases, the more likely it is that the surrounding pieces are automated. From there, you can simply optimize the production process itself to drive improvements in speed within the localization phase itself.

Use Project Duration Metrics to Drive Data-Driven Conversations

Bottom line, if you can break your project into stages that represent the full view of a project’s duration, and not just the localization portion, you can shine a light on areas that need stakeholder involvement in order to remedy things.

Also, this enables you to compare across different groupings of projects and stakeholders, to spot trends. For example, you might find that certain teams are more prone to delays in the “Scoping” phase, while others have the lowest average % in that phase companywide. What’s great about this is that you can use the “shining examples” of what great, efficient localization looks like in order to coach other teams toward the same results.

What this means is that when you meet with a stakeholder group, the conversation takes on a more helpful tone. Instead of answering questions like “Can’t you speed up the translation?” the conversation can turn toward, “How can we minimize the time spent in each phase?” Sure, there will always be things you can do to improve localization speed as well, but that’s not even 50% of the battle in most scenarios when we’re trying to improve speed.

Often, stakeholders don’t even realize they are burning up 50% or more of the total project duration in things like scoping, simply because their files and content are poorly organized to begin with. What we’ve learned on my team at HubSpot is that highlighting more about the “stakeholder-dependent phases” of any project is very useful to drive improvements in overall speed.

Driving speed improvements is a complicated topic, and as we all know, many stakeholders don’t have the patience to learn about this stuff. But, if it really matters to them, they will take the time.

The Ultimate Mission? Make Localization Extremely Accessible

I believe it’s our job, as people working in localization, to present information in a way that is easy for people outside our domain to understand and digest, and in ways that people are used to seeing within their regular business environment. Using a metric like “average project duration” as opposed to “turn-around time” is just one more step toward that mission.

Coming up with new ways to communicate these concepts is the ultimate exercise in “micro-localization.” 😉 We can’t just be experts in converting a digital experience from one language or culture into another. We have to also be experts in converting concepts from our native “Localization Culture” into business culture. That means positioning localization within jargon and business trends that matter for your company communications and culture. In my case, that means coming up with ways to communicate about localization that work for a fast-paced, high-growth, continuous deployment SaaS environment.

Sometimes, showing stakeholders a simple graph that shows the quarter-over-quarter changes in how long scoping is taking as a % of their total project volumes gives you a concrete way to talk about this topic, with the shared goal of speeding things up! It’s hard to get people, and entire teams, to change the way they do things. At most digital companies, everyone speaks the language of numbers. For that reason, numbers can often speak louder than words, and can drive change more effectively than any amount of blabbing on about localization best practices can do.

In summary, I believe average project duration is an important metric for localization leaders at digital companies, and one that can trigger a lot of helpful conversations. If you have experience with this or a similar metric, I would love to hear about it!