There is no such thing as a translation process
In this article I will show that the cause of the translation issues that most companies run into are related to their organizational structure. I will show the differences between managing a project and running a process, and argue that translation should be seen as part of the primary process, rather than being dealt with in a project organization. And how from this, it follows that you should not have a localization department that takes care of translations.
Traditionally, translations have always been seen as projects that are separate from the creation of a product. It feels kind of logical, does it not, to first create your product in one language, and then run a project in which you "just" translate it into multiple languages. And as it became more and more apparent that this actually required a lot of work, companies started hiring project managers so that the rest of the company could just continue doing what they were doing before.
People in this role know the premise behind this is simply not true: translation cannot be seen as independent from the content creation process. The effects of this misconception are quite dramatic: it creates an inequality between languages, leading to demonstrably worse results in international market penetration.
In order to solve this, Localization Project Managers are constantly fighting to get acknowledgement for the fact that they are running into problems because of what happens when the content is created. Their solution usually is to try to be advisors to all departments, basically telling people to change the way they work so the Localization Department won't experience as many problems. This usually does not work out so well. Most Localization Managers just hit a wall when trying to accomplish anything outside their own department. This leaves them being the person always trying to make people's lives harder - and the person who needs to solve problems in their project that were created elsewhere and that usually only come up right before the deadline.
A matrix organization - sort of
What most companies fail to see is that the issue lies in their organizational structure. In treating translations as projects, you establish a matrix organization - and a very special one. In matrix organizations you usually manage projects in order to improve the primary or supporting processes. In this case, the projects are meant to do additional processing on the products coming out of your primary, operational process. I will show that this is an inefficient and ineffective way of treating something that could possibly make the difference between international growth or failure.
Project vs process
First, let’s take a look at the terms project and process. Projects and processes might seem very similar, but they are fundamentally different in how you achieve results.
"Simply put, a process is a set procedure that involves a sequence of steps that need to be taken in order to produce a result, whereas a project is a temporary course of action that aims to deliver a distinctive product, service, or result." (Source: Zenkit Blog)
In other words, projects are one-off events, that have a fixed time, a fixed scope, and fixed resources. Project managers are to deliver the result on a deadline, usually without having to account for how they do this. If they run into problems, they usually fix it in an ad hoc manner, because the only purpose is to deliver on time.
Processes on the other hand run in repeatable cycles. Process managers make sure the process runs in flow and is therefore predictable and scalable. They detect bottlenecks and find the root cause. In order to solve these bottlenecks and improve the process, they often initiate small projects.
Although a lot of steps in a translation project are repeated over and over again (so you could argue it has aspects of a process), in most companies they are handled as projects. Budgets, translators, and other resources are allocated for the project specifically, style guides and terminology lists are created, scope must be defined, and a specific deadline is set. The project manager sends out files, instructions and a timeline to translators and other project employees.
The problem with projects
In order to understand what is wrong with this approach, we need to steal some insights from business management. Let’s start with some well-known terminology from Lean methodology: the value stream.
“A value stream is the set of actions that take place to add value to a customer from the initial request through realization of value by the customer. The value stream begins with the initial concept, moves through various stages of development and on through delivery and support. A value stream always begins and ends with a customer.” (Source: Wikipedia)
The focus on the customer gives the value stream its purpose. It helps you decide which activities in your primary process add value that the user is willing to pay for.
Translation is not considered to be part of this value stream and is treated in separate projects. This has as a consequence that it is hardly ever discussed, let alone measured, how bottlenecks in the translation part of processes affect the business goals, for instance in terms of time to market, opportunity costs, scalability problems and unfit content for foreign users. This also means that it is very hard to discover what MUST be improved in order to add maximum value for the end user.
This is one of the main reasons why localization managers have such a hard time getting their message across: it is almost impossible to build a business case around improvements, as you cannot measure how it relates to the strategic goals of the company.
The gap between the user experience and the translation projects also leads to a number of unresolvable issues that have kept localization people busy for the last decades. The most eye-catching of them all is trying to measure translation quality. From the viewpoint of the user, translation quality does not exist. There is only product quality (aka user experience), and measuring this should be a number one priority of your company.
Being separate from the value stream explains why translation is often seen as a cost center; no organizational structure or system is in place that can help you decide whether the activities that are executed actually add value for the user, and to what extent.
A necessary mind shift
The important thing to realize is that translation in itself is not something a user would pay for. It is the translated product that has value, for instance a software product. This is equally true for marketing content: the translation in itself is worthless, only in combination with a good marketing strategy, SEO and a medium to publish the content can it bring value.
So the task at hand is creating a multilingual product. The way your multilingual product is best created is completely dependent on the requirements of the user and can be different for each business process and each company. It can be that for some processes Machine Translation is perfectly fine, because speed is so valuable to the user and small translation errors are less of a deal breaker. And for some processes you should forget about translating altogether and choose instead for some form of co-creation, where content is produced in multiple languages at the same time.
But you can only know which method you have to choose if you can measure the effect of your improvements by looking at the business metrics. For this, you need to include making your product multilingual in your value stream. This means that translation becomes a part of your primary operational processes and should not be handled in a project organization, nor in a secondary process.
There is no such thing as a translation process, only multiple primary processes that have a multilingual component; one for the creation of a multilingual software product; one for the creation of multilingual support content; one for the creation of international marketing content, etc, etc.
Including these activities in your primary process is the only way to discover which of your activities add value to your product.
What happens if you move to a process?
If you view translation as part of your business processes, wonderful things happen:
- There will be a focus on process improvement, leading to faster turnaround times every single time you run the process. Delivering a multilingual product as fast as possible is the challenge at hand, a completely different challenge from 'delivering translations as fast as possible'. Eventually this will lead to delivering all languages at the same time.
- There will be no more discussions about translation quality and how to measure it; it will be about product quality and it will be measured in the same way as you do with your source language. If your product quality is not being measured, it might be wise to start there.
- Resources can be hired for a predictable number of hours every day or week. No more resource planning.
- Issues in translation will be solved where they originate. More often than not this is where the content is created.
- All activities that do not add value to the user experience are identified and removed, in most cases leading to far fewer review steps and faster turn around times.
- No more workarounds and band-aids in order to make a deadline at all costs, which complicates the translation part of the process incredibly.
- The task of project management will become obsolete, partially because of automation and partially because a process manager will create more collaborative workflows without the need for a middleman.
What do you need to do?
Including translation in your primary process leads to big changes in your organizational structure.
The most important role is for process managers who manage the primary processes. This role is usually already present in a company, although it may be called something different. The process managers need to extend their process to include the localization part of their product, whether it be a marketing product or a software product. The process managers’ main task is to understand where the process breaks, and why that is the case. In order to solve other underlying problems, they can call in the expertise they need.
Although a lot of issues can be solved by adjusting the process, there comes a moment where automation and other systems are the answer. The technical expertise needed for this is quite specific to content and localization management and therefore it is important to have access to someone who could be called a Product Owner for multilingual content systems.
In most cases, you will need translators. In order to eliminate project management, these translators will take on a much bigger role in your process, leading to more empowerment and less waste of talent - and leading to better results.
In order to understand what product quality means for your users, in all countries, it could be that you need language-specific customer success managers, or any other coworker that sells or talks about your product with real end-users. But in some cases you can get all the information you need by simply looking at the numbers and analyzing them for each country separately.
So what about localization experts, you may ask? People that really understand what it takes to transform content from one language into the other? Well. They’re already mentioned above. They’re called translators.
The end of localization departments?
This of course leads to the question as to what a translation department is supposed to do. As project management is supposed to be taken out of the equation - as a natural consequence of the improvements - and process management should be done on the entire process, so as to optimize the whole, I would say that there is really no need for such a department.
This is a big thing to ask from Localization Managers. They are probably the only people who can truly understand that this is inevitable and who can make this change happen, but they are also the ones who will need to give up their role as they know it, with no apparent alternative.