In the previous piece of the series, I covered the basics of recruiting for translation teams. Now this time, I’ll cover the core basics of project management as it applies to us in the translation community, with a focus on a few simple tools to think about.
Just what is project management?
Project management is an actual academic field that more or less comes under the umbrella of Operations Management and Management Science. Within that field, you get research into mathematical models for predicting and managing projects, as well as all sorts of processes to estimate costs of delays, identify scheduling issues and so on. Like with most areas of ORMS, there’s lots of money riding on these models, and huge corporations and governments are very interested in these tools.
We’re not managing huge projects, hell, we rarely break team sizes of 10. What this means is that much of the high powered cutting edge tools from the project management field is beyond overkill for us. Things like MS Project are great if you’re managing 20+ software developers on a time sensitive product that needs to report to upper management, not so much for 5 guys on irc just working together. So what I’ll be writing about will be things that you can figure out with a pencil and paper, maybe a spread sheet.
The basic goal of project management is to get a project done: on time, on spec, and on budget. For us free fan translation groups, things are a bit hazy to make a 1:1 mapping, but it’s close.
What’s a project?
What the heck is this project thing we’re managing anyways? Projects are things with a start, an end, and steps to get there. At the end, the project has some kind of deliverable, the completed widget.
Wrapped around the project is it’s scope, it’s the requirements and set expectations on the final product. It defines what you’re supposed to do and when it should be done, sometimes even how it should be done. The answer to “Will you do this?” should be “If it’s in the scope, yes, if not, no.” It’s primarily the project manager’s job to negotiate the exact scope of the project with everyone who has a stake in the project. They have to set the expectations and make sure everyone agrees, because otherwise an otherwise good deliverable can look like a failure because it didn’t meet the scope.
Translation projects naturally fit into this whole project scheme, more naturally than when people normally throw the word ‘project’ around. We have a set deliverable, the translated product, we have a fairly well defined scope, if it’s part of the script/engine we’ll work on it, and there’s a vaguish deadline ahead.
Some of you may have noticed that much of my previous writings in this series essentially make the assumption that I was managing a project in this sense. I think more aspects of it will become clearer.
Basic notion of ordering
Some things need to be done in order —- I need to put my socks on before I put my shoes on, sorry but that’s just how things are. Other things don’t have to be in a particular order —- I can look left then right at the intersection, or right then left, so long as I do both within a reasonable amount of time, it’s not too big a deal which I do first. We all understand this, and do it without thinking about it much in our day to day lives.
The heart of project management is identifying the tasks (and subtasks) that need to be done in a specific order, and those that don’t have to be. Without this, you can’t do any planning.
One of the most basic ways to represent the basic ordering of items is with a Gantt chart. Basically, you line up all your activities along the left, time goes along the top, and you make time bars representing how long an activity is going to take. You make sure that any task that must come after another task can only start after that task is over, by making sure the end of one lines up vertically with the start of another.
So for example, if you look at the diagram, you can see the tasks lining up. There’s lots of extra things like percent completion and the ‘today’ line, and all that, but those aren’t absolutely necessary.
However, Gantt charts do have flaws. You don’t get to show dependencies very well, so you usually have to draw arrows or other labels. If a project gets complicated, it becomes difficult to read pretty quickly.
However, it does provide a quick way to sketch out a rough schedule and give an estimate to how long something is supposed to take. Provided your estimates are good.
Critical paths and beyond
There are now much more modern (compared to Gantt charts) ways of looking at project dependencies. One major idea that is used in all sorts of PM techniques, and one that I believe will be useful to translation teams is the Critical Path Method or CPM.
The CPM idea is pretty simple. First you need to make a network diagram of your project and the tasks that need to be completed in order to finish. The easiest way to build this diagram is to make a start node, then draw arrows out to other activity nodes. You want to connect activities so that arrows coming into a node means that “this task needs the output of the task where the arrow comes from to be finished before it can start”. Sometimes, a task might require 2 or more arrows coming in, showing multiple dependencies. On the far side of the diagram, you have a “finish” node where you tie all the chains of nodes back into one thing. The diagram above shows all this and more. For those keeping track at home, this is an Activity on Node (AoN) diagram, there’s also Activity on Arrow (AoA) but they’re harder to read intuitively.
Next up, you can label the nodes with how much time they take, 8 weeks for translation 16 for editing, 1 week of testing before release. So far, you can do everything on paper with a pencil.
Looking at this diagram, and doing some simple addition, you can figure out how much time it takes to walk along the diagram, going from start to finish by following the arrows, and figure out how much total time each path takes. The path that takes the longest time, is called the Critical Path. Essentially, it’s the one where if there’s a delay on any activity on that path, the whole project gets delayed. Everything else has slack time, but not on the critical path.
There’s more things you can do with this network diagram, in fact, the huge PERT system which MS Project implements as part of its core features is based on the analysis, and more complicated variations of, this basic chart. However, we’re not going there. That’s overkill for us.
What we really care about
The critical path is what we’re interested in. We want to make it as short as humanly possible. The best way to do that is to check the critical path, and figure out if a task really has to be on it or not. Some things are unavoidable, you need to have the engine hacked before you can dump/insert text into it. You need to have a script translated before you can release. However, you don’t need to have a script translated before the script inserter is finished, and so on. To make the best use of the team, you really have to figure out what absolutely must be done in order, and what can be done in parallel, so pruning that critical path should be your #1 priority if you’re looking to cut down time spent.
In theory you can “crash the critical path” by throwing more people/resources at the problem, but it’s usually not as effective as you’d think, and it’s hardly possible in a tiny unfunded project. You could easily crash the translation phase of a project, all you need to do is hire one, or more, professional translators. Is it worth it? Can you even afford it? Probably not.
Tying things together
Back when I was arguing for small teams with multi-skilled people I mostly emphasized that managing fewer people, and having people who can help each other out was my reason for pushing for that idea. Now that I’ve explained what a critical path is, I finally can illustrate the overarching notion that led me to make that statement.
If everyone can do a bit of almost everything, you maximize your ability to avoid delays on the critical path.
Within a translation project, there’s a small number of activities that take a very long time. Translating, editing, and sometimes engine hacking. Everything else that needs to be done, testing, graphics, etc. all take relatively minimal time. So the critical path for a project is pretty easy to identify. You can make things easier by breaking translating and editing into staggered chunks along the way, but there’s a practical limit to what you can do to those. That’s just how things are.
However, there really should be no excuse for having a critical path delay on photoshopping some graphics. Nor for testing or proofreading (proofing, not editing mind you). Everyone can do these tasks in some way or other, and everyone should pitch in! If there’s two translators on a project, then they should work together so that one can pick up the slack of another in an emergency. No “it’s not my script, that’s his department so I won’t touch it“crap, just do it!
Most projects die because there’s a staff member on the critical path just leaves/stops working for whatever reason. Such delays can’t be allowed! It’s the project manager’s sacred mission to go and make sure everyone is happy/content and productive and everything is on schedule. If a replacement is needed, the PM should be working as hard as possible to fill the position to satisfaction. It’s the PM’s fault if a project dies and can’t be revived.
For the rest of the staff, it’s pretty important that they have a passing notion of what the task diagram looks like, at the least, enough so they know that “this really has to be done NOW because everyone is waiting on it.” People (usually) tend to be a bit more productive if they know that they’re being relied on, and while we can’t get away with setting hard deadlines here in the fan translation world, there’s much to be said about peer pressure.
Next time, I’ll write about the specific steps involved in the translation process! Hopefully, I don’t get hit with work so hard that I can do it sometime soon