Recently I was asked to define what makes a typical language translation project for our company. This was not an easy task as its difficult to define a ‘typical’ project for a small to medium sized translation agency. For us a project can be anything from a single language, single document translation, where the services of only one translator is needed to a multilingual, multi-document/file translation, editing and layout assignment where upwards of 80 plus suppliers need to be coordinated and managed.
Every project involves a ‘typical’ flow process (i.e. quote, order confirmation, placement with suppliers etc.) but obviously the resources needed to manage a single language/single document project are very different to those needed for a multilingual/multi-service assignment.
Having good PM tools is a real help and there are a plethora of really useful, well designed TMS (translation management systems) available to help translation project managers, agencies and companies manage large multilingual projects. At PS we don’t currently have a dedicated TMS that we work from and mostly our projects are run using the standard MS office suite (with the addition of MS Project – which I find really useful for managing all types of projects and MS Accounting for project documentation – POs, OCs, etc). Software alone however can only get you so far and in both instances (big project/small project) good practical project management is key to ensuring success.
Based on over 10 years experience of working on projects in the professional business services industry, here are my top 5 tips for project managers working on multilingual translation projects.
1. Be clear about what service you are offering/managing/requesting from a supplier.
Depending on the nature of your work, you may or may not be client facing and you may or may not be responsible for ‘selling’ translation services to the end client. If you’re not, be sure to define exactly with the person who is (i.e. the salesperson) what the expectations of the project are and specifically what level of service the client expects. Although this may seem a little obvious and most (good) agencies/LSPs will clearly define their provision of service prior to commencing work on the project, some don’t. Purchasing and ordering translation from a supplier is (usually) relatively straightforward, however post-translation services are not always as easy, principally because what one company/agency/translator calls proof-reading another will call editing, and another will call a review. These terms can all mean the same thing to one person but something very different to another and understanding (or defining) the difference between having text proof-read by a second mother tongue and edited by a second mother tongue can result in two very different end results. Be clear at the at start of the project what service you are managing and what your client requires. Make sure they (the client) understand what is involved in the level of service you provide and ensure this is acceptable to them. For multilingual projects this needs to be the case across the board for all languages, and providing all suppliers (translators, reviewers, proof-readers, etc.) with a service level agreement/ job specification document can be a great help.
2.Take stock of your collateral and your project resources.
Again this may seem like a bit of a no brainer and typically you find that by the end of managing a large multilingual multi-document project you feel you know the documents inside out and back to front, but its worth knowing exactly what you’re working with before the start. If you’re working with documents, go through them thoroughly and make sure that you understand their make up (layout, design, etc). By being as thorough as possible it will help anticipate any issues that the may come along later in the project or may have been missed during the quoting/tendering stage of the work. I always document all the files I will be working with in an excel file – the file name in one column and provide a notes section in the adjacent column (to make a note of any specifics/issues I can see with the files). Crucially, you need to understand/take stock of who will actually be carrying out the work (the actual resources). It may be you have had all resources fully lined up prior to the project getting the go-ahead or it might be you have the work and need to match it up with the most appropriate supplier. Make sure everyone is aware of what is required of them, they have all the resources they need (reference material, TMs, etc) and they will be able to comply with the delivery schedule. If the project involves multiple stages and these need to be time scheduled, it can be worth accounting for project risk factors (e.g. delay with text finalisation from the client, supplier unavailability, etc.) when working and agreeing a schedule with suppliers. Being able to keep both customers and suppliers happy with regard to delivery schedules is a key skill that translation PMs need to develop and master.
3. Create a system that allows suppliers to communicate with each other.
Some translation service providers have a very strict policy when it comes to sharing their supplier information – they simply don’t. My feeling is that if there is a valid reason for it, then allowing suppliers to communicate with each other (and the client when needed, if managed correctly) is not a bad thing. I have found that for multilingual multi-document projects, allowing the post translation proof-reader to liaise directly with source translator (for example) is the quickest way to get agreement/queries resolved. Both these individuals will be (should be) have the same mother tongue language and will have experience in their specific field of expertise. Who better to communicate with each other about issues relating to text specifics? Not allowing the proof-reader and the translator to communicate about project issues would be like not letting a programmer communicate with the designer during an IT project. I would add to this, as with any project, it’s critical that all parties involved (suppliers, etc.) understand the appropriate channels for communication/collaboration and that the remit of their requirements is clearly understood.
4. As the project progresses use PM tools to track the progress.
I am a big fan of project documentation. Having clearly defined and documented parameters are the cornerstone, I believe, of good project management. One tool I frequently make use of when managing a large multilingual multi-document project is excel and specifically the data validation>list option. Using this I create a list of project stages/processes the work has to go through (i.e. client create, delivery from client, with translator, with proof-reader, etc.) before delivery is made. This list of stages can then be applied to specific languages/files. The screen shot below is from a recent multilingual multi-file project that I managed, and you can see that the various stages of the project life cycle (i.e. the deliverable) are shown in the drop down. By updating this file continually you are able to keep track of project at a file level. When drawing up your list of stages try and be as thorough as possible – you can always add stages at a later date but it helps if you map every stage a specific file will go through before making your list. TecRepublic have a very simple guide to adding a drop down list in excel:
Using drop lists with mapped stages to help track files.
5. Use appropriate file storage and don’t deviate.
Whatever type of project you are managing you need to be organised and knowing where your project files are and how they can be retrieved is essential to the success of the project. You need, therefore, to have a standard practice for saving/archiving your files. There are many standards used within the language translation industry (EN15038 etc.) that stipulate how files and other project collateral should be stored and recorded. At the most simple level you should always have one place for your source files, one place for your working files, another for delivery and another for any admin related files (PO, OC, etc.) all encompassed within a main project folder. What goes into these files will vary greatly on the nature of the project and the specific requirements of the work. Try and be as thorough as possible from the start with your naming conventions of folders and don’t be tempted to just discard files in the main project folder. The naming convention of files should be checked with the client before any files are renamed and again the convention you use will vary greatly depending on the nature of your project. As a basic I will always append the delivery file with the language code (.fr, .es, .de, etc.) and usually (unless requested to keep the naming convention as per the original) I will add the job number to the front of the file name, and the version and date to the back (along with the language code). This may seem like common practice and in most cases this is the norm, however it is easy for project managers working on these project to get side tracked and miss/skip the naming convention/folder location etc.
I believe that good translation project management is a skill that can be learnt. Having great tools can only get you so far but the key is clear and thorough planning from the start and having a process that can be monitored throughout the project life cycle. I hope you find the above tips useful and would be very interested in hearing from others of their experience in managing large multilingual projects.