Translation project management: the complete guide for agencies in 2026

Translation project management looks manageable until you're running 20 active projects simultaneously and something breaks. A file sent to the wrong linguist. A deadline scoped around translation time only, not review and formatting. A glossary emailed two days after the translator started. These failures aren't random. They come from workflows that weren't designed with enough specificity.

This guide covers the phases of a translation project, where agencies typically lose control, and what decisions actually separate agencies running clean operations from those reacting to problems all day.

What translation project management involves

Translation project management covers everything between receiving a client brief and delivering the final files. The PM role combines file logistics, linguist coordination, timeline tracking, client communication, and quality control, often all at once.

At a small agency, one person might handle all of this across 10 to 15 active projects. At a larger one, a dedicated PM might carry 30 or more, often across multiple language pairs and domains. The work isn't technically complex in the way translation or DTP work is, but the coordination overhead is high and the margin for mistakes is low.

The standard workflow runs through roughly five phases: brief intake (capturing scope, file formats, language pairs, domain, and deadline); file preparation (converting files, applying TM matches, loading the glossary, setting QA parameters); assignment (matching linguist to language pair and domain); translation and review (CAT tool work, QA passes, query handling); and delivery (sending final files, archiving TM updates and glossary changes).

Most agencies know these phases. The issue isn't understanding them. It's maintaining consistent execution through all of them, especially when volume spikes or when someone new joins the team. The informal knowledge that one PM carries in their head doesn't survive at 30 active projects. Documenting those decisions is what makes growth manageable.

Building a project brief that doesn't generate rework

The brief is where most translation problems start. A brief that doesn't specify the target audience, required terminology, delivery format, or style preferences will generate queries and revisions at every downstream stage. A single underspecified sentence in a brief can cause three revision rounds on a 2,000-word document.

The most useful briefs answer five questions before the translator opens the file.

Who is the end reader? A legal notice reviewed internally by compliance needs a different register than a consumer-facing product description. If the linguist doesn't know, they'll guess, and the guess will sometimes be wrong.

What terminology is approved? Client-specific product names, regulatory terms, and brand vocabulary should be locked before translation starts. Even a 20-term glossary reduces revision cycles materially.

What file format is required for delivery? A print-ready PDF, an editable DOCX, and a TM export have different post-processing requirements. Finding this out after translation is done wastes time.

Are there existing TM assets? Getting the client's TM before the project starts reduces word count and cost. Many agencies skip this step on smaller projects and then end up re-translating content that should have matched.

Is there a style guide? Without one, linguists make stylistic decisions independently. One-off projects can absorb this. A product series or campaign cannot.

A brief template doesn't need to be long. A structured intake form with these five questions, answered consistently, does more work than an elaborate onboarding document that nobody reads in full. The brief is also a useful reference point when client feedback arrives after delivery, giving you something concrete to point to when a revision request goes beyond the original scope.

File preparation and TM before assignment

File preparation is often treated as a 10-minute admin step. It isn't. Sending a poorly prepared file to a linguist wastes their time and yours, and the resulting errors (missed segments, skipped glossary terms, broken formatting) are expensive to fix after translation is done.

Preparation means confirming the file is in a segmentable format, applying TM matches, pre-populating 100% matches and repetitions, loading the glossary in the CAT tool, and setting QA parameters before the linguist opens the project. For a 5,000-word project with a mature TM, this step can reduce the actual human translation workload by 30 to 40 percent.

Before assigning, run a word count analysis from your CAT tool. 100% TM matches still need review, but the time estimate differs from fresh translation. Fuzzy matches in the 75–99% range need more attention. Knowing the breakdown before you commit to a deadline changes both your timeline and your cost estimate.

Segmentation integrity matters more than most PMs realize. Inconsistent segmentation rules break TM reuse across projects. If your agency handles DOCX, XLSX, PPTX, and HTML files, each format needs correctly configured segmentation rules in your CAT tool. One wrong setting in a project template can silently erode TM savings across months of work.

The glossary file should be attached to the project before the linguist starts, not emailed separately mid-project. The in-editor terminology suggestion only works on terms that are actually loaded. If the linguist receives the glossary as a separate email on day two, some terms will be missed.

Format validation before handoff is also worth doing. Embedded images, tables, footnotes, and non-editable content need to be accounted for before translation starts. Layout problems discovered after translation (because a text box expanded or a PDF conversion dropped formatting) are expensive to fix at the end.

Assigning linguists by domain, pair, and capacity

Assignment looks easy when you have a full roster. It gets harder when you need a specific language pair and domain on a short deadline, and your usual linguist for that combination is already at capacity.

Domain fit matters more than availability for specialized content. A general translator is the wrong choice for a pharmaceutical protocol or a financial prospectus. Domain errors in those document types aren't just quality issues; they have real downstream consequences. Keeping domain notes against linguist profiles and filtering by them before assigning is not extra overhead — it's the minimum a quality-focused agency needs.

Language pair granularity is a common gap. Some agencies have several Portuguese translators but only one who covers European Portuguese reliably. Language variant matters for Spanish (ES-419 vs. ES-ES), Chinese (ZH-CN vs. ZH-TW), and Brazilian versus European Portuguese. If you're not tracking variants separately, you're making occasional mismatches, and you may not know about them until a client calls.

Capacity tracking is the part most agencies underinvest in. Assigning to your best linguist when they already have three active deadlines is a reliability risk. The question isn't whether a linguist is theoretically available. It's whether they have bandwidth for the specific delivery date, accounting for everything else they're currently running.

Communication history also informs assignment, though more quietly. A linguist who consistently asks clarifying questions adds time to projects, but that time is usually worth it. A translator who never queries anything is not necessarily more reliable; sometimes they're making judgment calls that should have been questions.

For multi-language projects, an assignment matrix listing language pair, linguist, word count, deadline, and query contact — shared before work starts — reduces mid-project confusion and makes progress tracking easier without chasing individual status updates.

Building a roster with reliable coverage for your most common language pairs and domains takes time. But maintaining basic records against each linguist profile (a few domain tags, variant notes, a simple capacity tracker) pays off immediately when you're assigning under deadline pressure.

Timeline planning that accounts for the full workflow

Translation timelines are often built around one benchmark: a professional translator can produce between 1,500 and 2,500 words of quality translation per day. CSA Research has cited this range consistently across multiple industry surveys, and it's a reasonable starting point for planning.

But the benchmark breaks down in predictable ways.

Domain complexity affects output significantly. Legal and technical content takes longer per word than general text. MTPE (machine translation post-editing) is faster per word than fresh translation but varies by content type and by the quality of the MT output going in. An MT output with consistent phrasing and few errors can be post-edited quickly. An output with structural problems, hallucinations, or terminology violations takes as long to fix as starting from scratch.

Revision rounds need their own time allocation, not shared time with translation. A one-pass delivery is faster. A two-pass workflow with an independent reviewer produces more consistent output. Most agencies building for reliability use two passes on documents going to a client for publication, and one pass for internal or lower-stakes content.

Client review cycles belong in the timeline from the start. Delivering a translated document on Tuesday doesn't mean the client can provide sign-off before the following Monday. Ask about the client's internal approval cycle at intake. If you don't, you'll find out the hard way on the first project.

Post-processing is the most consistently underscoped phase. DTP, layout restoration, and formatting work after translation can take as long as the translation itself for complex document types: annual reports, product catalogs, regulatory filings. If post-processing isn't scoped, it will compress something else — usually review.

One approach that helps: break the client-facing deadline into internal phases with their own end dates. Translation complete by Thursday. Formatted file ready Friday. Client review window closes Monday. This structure makes slippage visible earlier and gives the PM a chance to intervene before it compounds.

It's also worth telling clients upfront what the timeline assumes. If they understand that the schedule assumes two business days for their internal review, they're less likely to come back three days late with a change request that throws off the next project.

Communication protocols that prevent silent failures

Most project failures aren't caused by bad translation. They're caused by missing information that nobody thought to share, or by feedback that arrived in a format nobody could act on.

One clear contact point per project prevents a specific class of problems. Linguists should have a PM contact for questions, not the client. Clients should route feedback through the PM, not directly to translators. When these channels get bypassed — when a translator gets informal approval from a client contact who isn't the final reviewer, or when a revision goes straight to the linguist without PM visibility — both the relationship and the scope management suffer.

Query batching is worth explicitly requesting from linguists. A single message with five questions is faster to handle than five separate interruptions across a morning. It also prompts the linguist to read through more of the document before asking, which often resolves the question before it gets sent.

When clients return revisions, a structured format saves significant time. Ask for the source segment, the translation they received, their proposed change, and the reason for it. Vague feedback like "this doesn't sound right" is slow to act on. A structured format makes revisions actionable and prevents the PM from interpreting ambiguous comments into instructions that the linguist then has to re-interpret.

Status updates at predictable intervals close another gap. Daily check-ins for projects under a week. Weekly updates for longer timelines. A project that goes silent is almost always about to be late, and catching it two days before a deadline costs less than catching it on the day of.

QA as a workflow thread, not a final gate

Translation quality assurance is not a checkpoint at the end of a project. It runs through the whole workflow. The PM's job is to make sure QA steps are built into the timeline from the start, not compressed when a deadline gets tight.

Before translation starts, a source text review catches ambiguities, formatting issues, or unclear instructions that would otherwise turn into revision requests after delivery. A poorly phrased source segment translated literally may need a correction round that could have been avoided with one clarifying email upfront.

During translation, automated CAT QA checks — missing tags, number inconsistencies, glossary violations, punctuation errors, untranslated segments — should run before human review. These catch mechanical errors quickly and free reviewers to focus on meaning and register, where automated tools are less reliable.

Before delivery, a reviewer who wasn't the original translator should check a sample against the source, verify glossary compliance, and confirm the formatting survived export. For high-stakes documents, a full independent review is worth the time. For general-content work, a targeted review covering the first and last sections plus any technically dense passages is usually sufficient.

We've written more about how to operationalize QA consistently across teams and language pairs in how to standardize quality control across your translation agency, which covers the practical decisions behind running QA at scale.

Where to start if your current process has gaps

If you're looking to tighten your translation project management without changing everything at once, the intake brief is the most productive place to start. A better brief produces fewer queries, less rework, and less overhead for every person downstream. It's the one input that touches every phase of the project.

After that, look at assignment. Are decisions made on availability alone, or do you track domain notes, language variant granularity, and current capacity per linguist? That information changes the reliability of your delivery estimates and compounds over time as your roster grows.

Then build QA checkpoints into the timeline explicitly, not as extras that get cut when things run late, but as phases with their own time allocated. Quality problems caught in review cost a fraction of what they cost when a client reports them after delivery.

The broader infrastructure question — how intake, PM workflows, file preparation, and delivery systems connect — is covered in more depth in how to build a translation agency operations system that scales.

Most agencies that manage projects reliably at volume didn't build that consistency all at once. They added one better brief field, one assignment filter, one QA step that moved earlier in the workflow. The changes are small individually. The cumulative difference in how the agency operates is not.