“Standard” is a funny word. To techies it often creates a sense of relief (if it’s actually been adopted) but to business operators like LSPs it can create a real sense of panic. During the meeting I noticed more than a couple people who clearly heard the word standard, had it used in the context of defining how they run their business and it was all they could do not to run screaming from the room.
At first I thought I was just going to end up zoning out for the two hours as the topic only had tangential interest for me but a few minutes in the conversation the discussion seemed to be stalling/circling a bit and, well, I’m the kind of guy who likes to jump into discussions with both feet just for the hell of it – so I chimed in.
My big concerns out of the gate were twofold:
- No specific focus
The conversation was jumping from the 100,000 foot “Let’s examine and define our processes” right down to the 10 foot “how do we standardize fuzzy matches?” debate. To be successful the end result/goal needs to be clearly defined and those pushing it forward need to buy in. The reality is there are no wrong answers here but there needs to be one answer.
- The word “Standard”
As I mentioned above the word Standard can freak people out. In this case I’m also not so sure it applied to the highest level view of what the group appears to be trying to accomplish. Subconsciously it probably sounds a lot better to say you’re working on establishing a “standard” rather than creating a “methodology” but there’s a lot of baggage that goes along with the word.
At some point in the discussion I suggested that perhaps “Standard” wasn’t the right word and perhaps “Methodology” or “Best Practices” were more appropriate. Initially I got the sentiment that folks were happy lumping them together under the same umbrella but eventually even Don DePalma suggested we get a jar and every time someone said the word standard they’d have to throw a Euro in it .
Lumping them together didn’t sit well with me at the meeting but I rolled with it. Upon reflection I think it actually does the process a disservice. While Standard, Best Practices and Methodologies all fall into the same, very broad group, I think they each speak to very different levels of definition.
Hierarchy of Business Practices
I’d like to step back for a second and layout how I view all of the different levels that come into play when trying to define a business model or process. Starting from the highest level, 100,000ft strategic view right down to the 10ft tactical level.
While the notions of Best Practices, Methodologies and Processes are separated by fairly fuzzy lines I thing there is still a sense of hierarchy between them:
- Best Practices:
These establish the baseline expectation anyone should have of a Language Service Provider. They state what an LSP (or internal language department) should and should not perform as part of their business process. For example, best practices may dictate that an LSP has a Quality Assurance Methodology but not necessarily detail what steps that involves.
A Methodology covers a group of processes that an LSP will utilize to achieve a specific goal. A Methodology will detail what processes should be under taken to ensure they are putting out the highest quality translation. For example, the QA Methodology may dictate that each document must be peer reviewed and a client in-country review should take place. Again, in this case it won’t necessarily dictate what exact steps must be taken by each resource, just that they need to be involved and follow the prescribed review process.
These are the isolated processes that combine to make a methodology. Processes will generally reference a specific cluster of tasks related to a specific competency. i.e. “Project Intake”, “File Preparation”, “Translation”, “File Review”, etc.
Finally at the very base we have tasks and standards. These are essentially the building blocks of the entire system. These are the individual steps that a person must perform or a standard that elements of the project must conform to. Standards could be technical (XLIFF, TMX) or material (Standard for defining fuzzy matches).
It’s also important to note that components such as methodologies, processes and tasks/standards do not have to have exclusive relationships with the adjacent tiers. A Quality Assurance process may be reused in a variety of methodologies within an organization. And at the lowest-level standards and tasks will likely be reused numerous times across a business.
So Where to Start?
The toughest challenge is always, “Where to start?” – and this is where I think the conversation largely got stalled in Berlin. We were flipping back and forth between notions of Best Practices/ Methodologies & tasks/standards. Again, neither answer is wrong, but you need to pick one and roll with it.
At the end of the day, regardless of what level you start at the outcome has to approachable, attainable and agreeable (AAA) to the people who you want to have adopt it, in this case the LSPs.
If you start at the bottom then it’s important to pick a narrow, defined niche and explicitly define the task or standard. If it meets the AAA measure you should have no trouble getting organizations to adopt it, especially if it’s merely defining something they already do. People love to be able to say they comply with something.
My personal approach though would be to start at the very top. Define the broad best practices – by doing this you create the buckets that you will need to back fill with methodologies. Processes, tasks and standards. As an industry body GALA can, over time, begin to roll out sanctioned methodologies & standards but by defining a broad best practice it gives everyone a chance to contribute.
If GALA were to bring to market the “GALA Best Practices for Translation Service Providers” they could outline the methodologies and processes that a client should expect their translation provider to have adopted. These best practices should outline that the translator has a clear and stated policy with respect to fuzzy matches, a methodology for identifying and assigning ‘best fit’ resources to projects, a clear and stated policy on translation memory ownership, a defined Quality Assurance process, and so on.
By identifying these best practices GALA would have created a plan from which to build out all of the necessary methodologies, processes, standards & tasks. And best of all, as organizations begin to adopt these best practices they will in turn start to creat
e their own methodologies etc., as those get shared back into the community they can help shape and define the GALA standard. Additionally, a Bet Practices standard gives member companies something they can achieve without (potentially) having to radically alter how they do business – which makes it far more approachable.
These are just my thoughts on the issue – I hope the conversation continues as it is really worth having and I think, over time, could contribute greatly to the business of all GALA members.