Global Pragmatica LLC®

This article was originally published in slightly-edited form by Multilingual magazine, April/May 2009 and is reprinted here with permission. Erin Vang would like to thank both Multilingual and her co-author, Tina Cargile, PMP, for graciously consenting to republication of these articles in the GlobalPragmatica blog.

POINT: The “right” way to communicate depends on the other people

Erin Vang, PMP

I once started writing up communication guidelines for all the project managers involved in my program (including several at vendors) and after several pages decided that I’d better keep it to myself, because my list made it far too obvious how neurotic I am. Some of the greatest hits I later culled from that list for a slightly less neurotic-looking set of guidelines:

1. Always put the project codename in the subject line (and various details that boiled down to “do me a favor and spell it correctly”).
2. Also include a hint about the actual subject in the subject line (don’t just reply to whatever I sent you last to save yourself the trouble of starting a new thread)
3. Please! No emails just to say “thanks.” Let’s just agree that we’re all grateful and polite and save the thank you emails for the truly heroic deeds.

And then there were guidelines to avoid the CC-proliferation problem—where you CC one person on an email as an FYI, and then the reply comes back with a few more questions and a few more CCs, and so on, and before you know it everyone from the vice president of your company to the assistant vacation substitute for your project manager from two years ago who’s no longer with the vendor are all involved in a lively discussion of whether Coke is “pop” or “soda.” (True story, only slightly exaggerated.)

Did anyone notice that I started right off with email and wonder why?

I didn’t think so.

Which brings me to my real points, which are far more important than learning anyone’s list of email pet peeves. First, the only right way to communicate is the way that works for the people on both sides of the communication. Let me illustrate with an example:

Not long ago I needed to discuss something with Tina, my collaborator in this “Point/Counterpoint” column. I didn’t want to write email, because the subject was sensitive, and to me it was quite urgent, so I phoned her. When she didn’t answer, I left voicemail describing the situation and asking her to call back. She never quite got back to me, which was frustrating. Sooner or later we did get in touch and worked it all out, but it didn’t happen quickly, and I couldn’t figure out why…

…Until recently, when Tina and I were exchanging ideas about this very column you’re reading now. She wrote, “It is clear that everyone has their own best ‘receiving’ style. For me, it’s written communication—gives me time to research, reflect, and basically not screw up my answer. I’m guessing you like the phone better, or maybe it’s a mix. I have an aversion to phone calls—it’s like a command to stop what you’re doing and thinking about. Maybe it’s a generational thing. Long distance was verboten when I was young—unless someone was near death. If they were already dead, a letter would do. And we wrote lots of letters.”

There was my answer—it was my fault! Although I’d left voicemail and asked her to call me back, I had intentionally made my message sound patient and low-key. Why? Because I was likely to be asking Tina for a pretty big favor, and I didn’t want to be pushy about it. (That’s how I was raised!) Next time I’ll know that unless I make it clear my voicemail is urgent, I’d be better off sending email.

As for my preferences, Tina guessed correctly: I prefer a mix of email and phone. For anything easy or brief, I start with email, for many of Tina’s reasons plus a few of my own. I don’t like to interrupt people. Often the details will be easier to understand visually than aurally. Email is often faster.

However, for anything tricky or lengthy, I switch to phone. I’ve found that many people either can’t or don’t understand things completely and accurately when they have to read more than an inch or two of text, and some topics are too complex to convey in two inches. In this case, a phone conversation is usually a better idea.

Unfortunately, writing a six-inch email is often the best way for me to think through the issues and state them clearly. If I just pick up the phone, I’m likely to frustrate the other person with a lot of circling around and unnecessary detail. In such a situation, I’ve found that it’s best to go ahead and write the long email to get my own head clear. Then I save it in Drafts, pick up the phone, and discuss the big concepts with the other person. Later I’ll follow up with email as needed to chase down final answers and details—and with any luck, the follow-up email will be much shorter and simpler than my first draft. [More on this idea within a blog post about meetings.]

One more point: both parties are responsible for both the sending and receiving of every message. I’ll explain.

For the sender: Don’t assume that just because you’ve said it or sent it that the other person has heard it or received it; lots of things can go wrong, including simple human error. (Have you ever read a message and then accidentally filed or deleted it before you replied or took action?) Also don’t assume that the other person has understood it. Even short, simple messages can be misunderstood. It happens all the time. Until you receive a reply that demonstrates the other person received your message and understood it correctly, you are still responsible.

For the receiver: Don’t assume that just because you’ve heard it or received it that the sender knows that. If it’s urgent to that person, have the courtesy to reply, even if only to say, “I’ll get back to you on this later.”

Does that contradict my third email rule, “No emails just to say thanks”? Sometimes. And if you talk to my project managers, they’ll tell you I’ve often left them dangling, not sure whether I received their important deliveries or not. They think it’s a stupid rule and I need to get over it. They’re probably right. Frankly, this is something I need to work on. I don’t like to reply before I’ve confirmed or answered everything in the email, because if I see that I’ve replied to a message, I’ll sometimes mistakenly assume later on that since I replied, that email is “done” and I can file or delete it. To avoid that mistake, I prefer to wait. Unfortunately, sometimes it’s taken me a while to get back to it, and in the meantime the folks on the other end might really need to know whether they can bill me, or release a resource, or go home to bed, or whatever.

Which brings me to my last point: most of us need some work on our communication skills, and in the meantime, we owe some apologies when we drop the ball. To all my project managers who have wanted to smack me for too often not sending timely replies: you know who you are, and if you’re reading this, I’m sorry!

COUNTERPOINT: Be clear about what you need, and consider your audience

Tina Cargile, PMP

As Erin says, there are different sending and receiving styles and preferences—lately it has been fashionable to complain about email, but there are complaints galore out there regarding both verbal and written communications.

We work in an industry that is all about meaning and communication, yet we don’t do much better than folks in other industries at employing effective messaging. There are missteps and irritants possible no matter how one sends a message–either phone or email. How often I have written a draft message and then returned to discover that what I “said” wasn’t what I “meant” at all! Or realized that the receiver was apt to see any suggestions as criticism, which called for a softening of the message.

As a lousy notetaker with a decent, yet aging memory, storing the call notes is essential—but by the time I get around to doing that, some details might have drifted away. With email, I can review every word and confirm that I received the complete message.

Finally, I’m trying to keep up with three different phone numbers (home office, office, and Blackberry), but I can always go a single place to check email when I’m about to board a plane or walk into a client’s office. It might take a couple of hours before I get a moment to check voicemail messages on all three phone lines.

I agree with all of Erin’s ground rules for email communication—having received one too many messages that essentially say “Hey, you know that thing we were talking about a couple of weeks ago? I vote yes.” Huh? Preparing a coherent message includes some preparation. Don’t assume I remember what we talked about a couple of weeks ago—I’ve slept since then.

The same goes for phone calls—I love Erin’s idea of composing an email to get your thoughts in order, and then placing the call. Nothing is as irritating as spending 15 minutes on the phone with someone who clearly doesn’t have a handle on the question they’re trying to ask. Except maybe those who don’t have the information handy on the subject of the call (“hold on for 5 minutes while I print all of this information out”). I usually request that they call back once they have all the data in order. Nicely, of course. [Erin’s comment: I once apologized to someone for answering their call at a time that was inconvenient for them. They didn’t get it.]

In fact, when planning a call to discuss complex issues or a number of related topics, I find it useful to send a call agenda before the call, if possible. Bullet points only! This means the receiver has some idea of the scope of the discussion and can be prepared with supporting information, status, what have you, before I dial the phone.

There are also differing schools of thought among those email aficionados among us. For example, some of my colleagues prefer that I gather up every single topic or action item needed that week to be sent in a single email. I can assure you that such an email would filter down and down in my Inbox; at the very least, I would likely miss one of the to-dos as I circle back to the original email over and over again. Personally I prefer discrete, individual messages, at least grouping by a single topic. This way, I can complete a task and it’s done and done!

On the other end of the spectrum, I despise voicemail messages that say “call me!” If there is a sensitive communication that you’d rather not write down, at least give me a hint. Often I will call back and find that the issue is something I could have researched and been ready to answer right then—but I have to call them back again, once I’ve gathered the information needed to answer.

I agree with Erin completely about the no “thanks” rule. If you must have a response within a certain time–don’t be shy—tell me! Another option is to request a read receipt for urgent matters only. I’ve run into correspondents who request a receipt for every single message they send, which tends to dilute the impact when something is truly time-sensitive or urgent. As I’m fond of saying, “when everything is urgent, nothing is urgent.”

Whichever “tools” you use to send and receive information, the most critical task is to be clear about what you need or are asking, and to think about the preferences of those you’re communicating with. It makes life much easier to remember that this client always wants a phone call and that client responds to voicemails with an email reply.

Finally, read your message before sending with the personality of the receiver in mind. Whether or not you meant to say “you really screwed up on this,” some receivers will hear that nonetheless, unless you include a line like “great job on this! I have some ideas that may or may not be useful—you let me know.”

This article was originally published in slightly-edited form by Multilingual magazine, Index 2008 & RD, 2009 volume, and is reprinted here with permission. Erin Vang would like to thank both Multilingual and her co-author, Tina Cargile, PMP, for graciously consenting to republication of these articles in the GlobalPragmatica blog.

Interoffice games and politics are nothing new; the trick is to avoid gunplay in the hallways. Few office relationships are more tenuous than those between project managers and salespeople. The following is an attempt to uncover what drives both crazy.

While both parties share a common goal—the overall success of the company—their individual stress points are quite different. Sales is concerned with client retention and frankly, making a decent living. Project managers are concerned with client retention and having a decent life. It turns out that your “decent” and my “decent” are often in competition. —Tina

Point: Top Ten Ways to Drive a Salesperson Crazy

Tina Cargile, PMP

#1: Keep bad news close to the vest

When a project is going south, please don’t let me know.

C’mon! I am trained to finesse the situation and provide solutions for the client. Your proactive communication helps me come up with alternative delivery scenarios. Often client-side milestones can be adjusted with early-enough discussion.

#2: Don’t address hazardous turnaround times.

Saying “well, OK” to tight turnarounds is great, and seems like a team-friendly attitude.

C’mon! When the turnaround is perilous, let me know! Better to arm me with an immediate counter-offer than to wait until the last minute to declare the project at risk (or hopeless). When a client asks for our best turnaround time, don’t ask me what they want, since the answer is typically “yesterday” and we both know that’s not going to happen! Tell me  instead what we can reasonably offer and I can try to make that work.

#3: Argue with me about “freebies.”

Sometimes it is necessary to shave margins to bring in a new client or to keep an unhappy client in the fold.

C’mon! I understand that you want to keep your margins in good shape for your next annual review, but keep in mind that some margin is better than none at all. You might also keep in mind that lower pricing means lower commissions for me, too. It’s not like I’m giving away your farm; I’m giving away a few acres of our farm to keep us in business.

#4: Accept escalated deliveries from the client no matter how questionable.

No need to call special attention to problems; I can read your mind.

C’mon! You might be copying me on project communications every single day, but you can’t expect me to realize when your polite “no problem” emails really mean “big problem!” I’m not involved in the day-to-day workflow, and your gracious, patient replies to the client look as calm to me as you mean them to look to the client. When there’s a problem, you need to speak up and get my attention!

#5: Send me a laundry list of questions for the client, rather than proactive suggestions.

Phrase every possible concern or objection in the form of a polite question.

C’mon! We are supposed to be the experts in our industry. Many of our clients are not as well versed, and consultancy on linguistic issues is part of the service we sell. Asking a client new to localization questions like, “How do you want us to handle text expansion?” is not a winning strategy. Instead, suggest options based on your expertise—nine times out of ten, the client will be grateful for the guidance.

#6: Tell me what you think I want to hear.

Tell me everything’s on schedule and on budget, and there are no risks.

C’mon! Happiness is a private matter; this is business. I have a job to do, and ugly information is best served sooner rather than later. I promise that I won’t resort to violence. Or even sarcasm. Well, maybe sarcasm.

#7: Keep me guessing

I don’t really need to know what’s going on until it’s hopeless.

C’mon! Both of us are probably working a 24/7 schedule, but please make it possible for me (and you) to fit in a little “private” time by letting me know about problems before they’re emergencies.

#8: Tell me you’re “swamped.”

C’mon! I probably am too, but learn to ask for help when you need it. Keep the focus on client needs.

#9: Keep customer complaints under wraps

It’s better to hide problems and hope not to get in trouble.

C’mon! I can’t address issues if I’m in the dark. I’m your partner, not your adversary. Don’t worry about failures; they are an opportunity for lessons learned and continuous improvement. Think of me as a client/PM advocate—I truly do see both sides.

#10: Give me grief about my “glamorous” travel schedule.

I’m just flitting around while you’re working hard, so it’s okay to give me grief.

C’mon! Yes, I travel frequently and stay at nice hotels. But most of the time, it’s just another hotel, I rarely see the city I’m visiting, and the presentation—whether at a conference, a speaking engagement or a client visit–is fraught with sore feet, exhausted facial muscles from smiling, time away from family, and airport misadventures.

Counterpoint: Top Ten Ways to Drive a Project Manager Crazy (whether you’re my colleague or a vendor)

Erin Vang, PMP

#1: Keep bad news close to the vest

When you’re running late or can’t get a component working, please don’t let me know, even though I know the schedule and feature lists were just best guesses that would need to be updated as reality came into focus. It’s really better to leave me in fantasy-land.

C’mon! Let me know what’s going on! If it’s a minor change, I can probably juggle things to make it all work. If it’s a major change, then I need to get started on helping management come up with a Plan B.

#2: Don’t address hazardous turnaround times.

Keep it to yourself when the official schedule is bogus, because it’s not your job to announce when the emperor has no clothes.

C’mon! We’re often asked to sign up for “fantasy schedules,” knowing that the true release date will be much later, but who does that really serve? The boss? No, the boss is staking his or her credibility on it, wants to know the truth, and s/he probably doesn’t realize how afraid you are to say it. The customers? No, the customers have production schedules riding on our delivering when we say we will, and they don’t really care if that’s sooner or later—they just want us to say when and stick to it.

#3: Argue with me about “details.”

Sometimes it’s hard to get all the niceties of a new locale working—like currency formats that don’t expect decimal places. Why can’t we just show prices in yen with two digits for centi-yens?!

C’mon! I understand that these things are tricky, but prices in Japanese yen don’t have decimals except on the Nikkei. If we don’t get the decimals right, we might as well not support yen at all. It’s not “a picky little detail,” it’s a requirement!

#4: Shrug and say, “Sure, we’ll make it work,” even when you know you can’t.

You might be rolling your eyes and thinking I see that over the phone and know what it means, but when you say you can do it, that’s what I expect you to do.

C’mon! If it can’t be done or it can’t be done on time, or you’re just not sure, say so! We can work with the truth. Empty promises get us nowhere.

#5: Send me a laundry list of doubts rather than your best estimate of what will happen.

When I ask you to estimate your time (colleagues) or quote a project (vendors), please list the eight million things that could go wrong.

C’mon! I know you need to cover your… um… bases, in case what we deliver is wildly different than stated, but do we really have to dwell on every possible risk? Can’t we just agree on baselines and come up with a contingency plan to resolve the inevitable discrepancies?

#6: Tell me what you think I want to hear.

No matter what I ask, just smile and say, “Right away, ma’am.”

C’mon! What Tina said! When I come to you with questions, it’s not to be polite, it’s because I really want your advice. Vendors: if we’re doing something stupid, tell us, and help us figure out a better way! Colleagues: if my questions are bizarre, don’t just answer them—help me figure out what it is I don’t know. I promise not to get defensive or embarrassed. Well, maybe embarrassed.

#7: Keep me guessing.

I don’t need to know what’s going on until it’s hopeless.

C’mon! Both of us are probably burning the midnight oil, so I understand that you feel bad about it, but your delay of “just a few days” is my headache of telling twenty people that our deliveries are late and, yes, they could have taken the holiday weekend off after all, now that it’s too late for them to book train tickets. I’d rather know sooner, and so would they.

#8: Tell me you’re “swamped”

It’s okay not to answer my emails if you’ve got a lot going on.

C’mon! I’m short on sleep just like you. You know that some of my questions need answers right away, and getting back to me two weeks later doesn’t help. Please give me the courtesy of a yes, a no, or an “I’m stuck until I get a decision from so-and-so.” I might be able to get so-and-so to make the decision that gets you unstuck.

#9: Keep problems under wraps. (This is another one for vendors.)

If you can’t figure out what our strings mean, it’s okay just to do a word-for-word replacement and hope the customers never see it.

C’mon! Some of our strings are lousy, but that doesn’t mean our customers don’t need to understand them. I’m your partner, not your adversary—don’t feel stupid about having to ask for explanations. The truth is you’re the best editors our product has ever had, and if it weren’t for you, even our English product would be a mess. I’m grateful when you call attention to the problems.

#10: Give me grief about my “glamorous” travel schedule. (Back to colleagues.)

I fly a lot, stay in hotels, and eat out on the company dime, and you’re stuck at home, so you have every right to be jealous.

C’mon! Yes, I’ve got “platinum-butt” status with the airline, but it’s not like I’ll ever have time to cash in all those miles on a vacation. What you might not realize is that I’m “on stage” from 8am until 10pm and then I start dealing with email. There’s never any time to do laundry, so I’ve worn my underwear right-side-in, inside-out, frontwards, and backwards. I’m gaining weight from all the meals out, I’ve watched all the TV shows on my iPod twice, and I miss my dog.

Look, we all face challenges and endure anxiety —that’s why it’s called work. If we’re honest about what’s difficult, though, and if we cut each other a little slack on the tough stuff, we can usually find a path to mutual success, or at least avoid dismal failure. Finger-pointing just makes us all bitter, but sharing responsibility and accountability for the bad as well as the good brings us together and enables us to grow as partners. Later on the “war stories” will unite us in laughter (if we remember to celebrate with a few pitchers of beer). Nobody will remember the easy successes.

This article was originally published in slightly-edited form by Multilingual magazine, October/November 2008 and is reprinted here with permission. Erin Vang would like to thank both Multilingual and her co-author, Tina Cargile, PMP, for graciously consenting to republication of these articles in the GlobalPragmatica blog.

Point: All five, all the time!—but mostly quality, time, and scope.

Erin Vang, PMP

Project managers talk about a “triple constraint:” scope, time, and cost. These are the three constraints where a change in one forces a change in the other. Increase the scope of a project (the amount of work), and you need either more time or more money to pay for overtime and extra people. Decrease the time available, and you’ll spend more on resources or need to cut down the scope somehow. And so on.

The triple constraint is usually drawn as a triangle with each constraint at a vertex and a haunting reminder of what’s really at stake in the middle: quality. The idea is that if you don’t keep all three in control, quality suffers.

Traditional project management triple constraint

A different triple constraint makes a little more sense to me—time, cost, quality—because it’s a no-brainer that more scope means more something else (cost or time or both), but what deserves our attention is how messing with cost or time affects quality. You can boil this triple constraint down to a pithy,”Good, fast, cheap; pick any two.” Or as a contractor friend of mine jokes, “If you want it bad—” (wait for it!) “you’ll get it bad.”

Even that triangle isn’t quite right, though. Let’s go back to the PMBOK where five constraints are listed: scope, cost, time, quality, and risk. Quality isn’t a result of your other choices, it’s one of the constraints, and you have choices about it. Risk is a constraint, too. Many project managers throw up their hands and ignore risk, but the thing about risk is that—here comes another cute line—”failing to plan is planning to fail.”

So we should be talking about a quintuple constraint, and the correct image is a pentagon. Let’s make quality and scope green (because more is usually better to our stakeholders) and the other three red (because less is better).

A better diagram is a quintuple constraint

The idea is the same: mess with any one of these, and at least one of the others also changes. But instead of drawing a warning “quality” in the middle as if it’s an uncontrollable result, and instead of ignoring risk altogether, we include both as the constraints (and choices) that they are. Our job is to execute projects with all five constraints in balance.

The shaded area inside the pentagon shows which of the constraints are most likely to keep me up at night in my work on the client side: quality, time, and scope. Some of our customers use JMP® software to make life and death decisions, so quality is paramount. We’re chasing tough deadlines, though, and keeping the scope under control is never easy. I am on a budget and manage a variety of risks, but cost and risk don’t usually keep me up at night because I can manage them over the long haul. It’s quality, time, and scope that have me putting out fires.

Tina on the vendor side wrestles with all five, too, but in different proportions that vary by client and project.

Counterpoint: Right now, it’s cost and time—but ask me again in 10 minutes!

Tina Wuelfing Cargile, PMP

When Erin and I first began collaborating, she introduced me to her five-constraint theory. At first it seemed odd and redundant, based on my traditional project management training on the triple-constraint theory, but the more I thought about the complexities of our industry and my client-facing role, I realized that I had intuitively been applying five constraints all along—I simply had not identified them as such.

As a multi-language vendor working in a wide array of verticals, I’m constantly looking at the question of determining fitness for use. It is one of the most difficult interrogative skills to learn or teach. Some claim that it is the client’s responsibility to communicate their goals accurately, which is technically correct, but I think serving in a partnership role with clients who may spend less than 10% of their time on translation projects is a more forward-thinking approach. Simply saying “Sure! You have a corporate bank account? We can fly you to the moon and back in two hours!” is not a winning long-term strategy.

Our primary industry sectors include legal, medical/pharmaceutical, and energy, but within those sectors, very different needs and roles emerge.

Legal translations involve the most diverse variations of constraints—from basic fact-finding, where time, scope and cost may be paramount, but quality and risk may be less important–to patent filings, where quality and time are often most important.

Medical/pharmaceutical work generally demands the highest levels of quality. Some translations just need basic research, but others have legal implications and need considerable vetting. Cost is not necessarily a primary factor, and an experienced project manager should advise the client on the risk of attempting a rush translation—often the rework needed to reach the necessary quality will erase any gains from rushing. PMs can assist by breaking the project scope into smaller, rolling deliverables.

Energy is a mixed bag—material safety data sheets (MSDS) must have top quality, and time and cost are usually not as critical.

Marketing materials for any of these verticals often have limited scope and time, but quality implications come first. Parsing trendy, creative writing aimed at US residents into text that makes sense abroad is one of the most difficult tasks we ask of our translators. (But seeing your company’s translation of an advertisement for disposable diapers is oddly thrilling!)

Whatever the business sector, risk management is what keeps me up at night. I work hard at proactively advising clients early and often about risks. Risk typically falls under the umbrella of cost but is inseparable from the other four constraints, in ways that can affect both client-side and vendor-side operations.

On the client side, say Big Pharmaceutical Corporation ABC who’s scheduling patients worldwide for a clinical trial or finalizing FDA submissions, a late delivery from us can disrupt hundreds of scheduled activities and milestones. My job is to understand the sequence of events that will unfold after our delivery, so I can advise the client upfront and help weigh the risks.

Risk is also critical for the vendor serving Big Pharmaceutical Corporation ABC. A delayed FDA submission might only lead to lower/slower revenue, but a translation error involving dosages or warnings could lead to patient illness or death. It is possible to limit our financial liability, but we could never limit our culpability or repair our reputation. So, I’m all for client education, but my focus is on providing leadership and consulting to avoid catastrophe. There is not a sleepless night nor weary day that I lose sight of the importance of the work we do and responsibility that we hold for our clients.

This article was originally published in slightly-edited form by Multilingual magazine, July/August 2008 and is reprinted here with permission. Erin Vang would like to thank both Multilingual and her co-author, Tina Cargile, PMP, for graciously consenting to republication of these articles in the GlobalPragmatica blog.

Tina Wuelfing Cargile, PMP, began her career at the Chronicle of Higher Education, as Director of Business Operations, moved to Austin, where she supervised the construction of a recording studio and managed that operation for several years. She found her way to McElroy Translation in 1988, fell in love with the industry and the company. She has served as Production Manager, Senior Project Manager, and has finally crossed to the “dark side” as Business Development Manager (aka Sales). [Note: Tina has since left McElroy to pursue other opportunities that we cannot reveal just yet.]

Erin Vang, PMP, is International Program Manager of the JMP R&D division of SAS, the world’s largest privately-held software company and serves on SAS’s corporate terminology management steering committee. She combines her enthusiastic study of facilitative leadership and her Project Management Professional credential with considerable domain expertise gained through twenty years of experience in statistical software documentation, quality assurance, project management, and localization. [Note: Erin has since left SAS and founded GlobalPragmatica.]

About this new column…

Tina Wuelfing Cargile and Erin Vang had never met each other when they began collaborating on a presentation for the Translation World Conference in Montreal in March of 2008. They had both submitted proposals on project management, and when they were asked to share a session, they decided to present a debate, because their original proposals took essentially opposite positions. While working out their game plan together, they found that their views both converged and diverged, and it soon became apparent that the challenge would not be how to fill the hour but how to pare down their many ideas to fit into the hour.

Both are seasoned project managers and PMPs (Project Management Professionals, certified by the Project Management Institute), both have music in their career histories, both rely on caffeine to get through days that are too long and too busy, and that’s about all they have in common. Tina works in sales for a localization vendor, and Erin works in R&D for a software company. Their professional responsibilities could not be more different, yet both are considered localization project managers! They decided to compare their perspectives on many facets of localization project management in a series of point/counterpoint columns for Multilingual Computing.

POINT: Establishing a project management culture unlocks team potential.

Tina Wuelfing Cargile, PMP

My first exposure to project management came years ago in the publishing industry, as we tackled the monumental task of converting from hot-type printing to electronic printing. We ultimately succeeded, but it took many more hours of effort and coordination than I ever could have thought appropriate. After transitioning to the translation/localization industry, I found that the complexities of project management were only multiplying as I gained experience.

In getting to know other project managers in the industry, I learned that I was in the majority for having had little formal training. We were churning and burning ourselves out in an effort to keep projects under control, monitor what was afoot, and try to learn from our mistakes

I also realized over time that many of my clients had become successful by adopting a structured approach to project management for their own work, which set me on a course of study and ultimately certification in the Project Management Institute’s (PMI) approach.

I recognized that many of the techniques put forward by PMI were far too complex and time-consuming for the average translation project, but it occurred to me that there were plenty of techniques that would be useful for our teams doing production, editing, translation teams, etc. That realization, along with my mounting frustrations from using my “hub of the wheel” top-down approach, led eventually to my reaching the following conclusion:

Traditional project management tools and techniques can work, even in our industry. However, traditional project management structure, with its centralized, top-down approach, produces little of benefit. Instead of greater productivity we get a baffling array of plans and graphs that are meaningless to the diverse needs of stakeholders in our industry.

I propose that we find the middle ground. By letting go of the centralized control but teaching project management knowledge, tools, and techniques to more stakeholders, we can empower them to manage their part of the process more effectively. Basic PM techniques help all of us reach the benchmarks of our particular specialty.

As Erin and I stressed in our debate in Montreal, context is everything. Readers who have attended industry events or read Multilingual Computing and other publications are aware of the diversity of structures and processes in the vendor side of our industry. Some companies have in-house translators, others outsource most of their work, and still others, like my company, employ a hybrid. Between my arena, and Erin’s, on the client side, the challenges are even more disparate.

We have clients, translators, and partners worldwide, in virtually every time zone. The challenges inherent in creating communication plans alone can be daunting.   Making smart use of technology and empowering virtual teams to work autonomously keeps us out of the “all-nighter” business and allows our project management team to stay lean and mean. (The mean part becomes most evident when I’m requesting a scope change for the third time.) We have hundreds of projects in process at any given time, and we have a combination of  routine work that fits into our defined workflow system and more  customized work that demands a creative, hands-on project manager. We struggle to define and manage myriad constraints, and our list goes way beyond the usual game of Time-Cost-Quality-Scope-Risk whack-a-mole

These are all subjects for future columns.

Another benefit of learning traditional project management is that it gives us a common language with our clients who “speak PMI.” Both as a PM and in sales, I’m process-oriented and try to get as much information as I can about my clients’ internal (sometimes infernal) processes, and having a shared language makes syncing up our processes that much easier.

Keep your company’s structure and needs in mind when determining which techniques to adopt. Equip yourself with whichever tools you can handle and need the most, and help your stakeholders learn how to navigate them and thrive with less pain. But don’t box yourself or your stakeholders in. There are many approaches to project management, and the body of knowledge, whether sanctioned by PMI, or not continues to evolve.

If you’re starting at zero, for heaven’s sakes learn some project management basics! Don’t reinvent the wheel. Project management will help you get rolling and stay organized.

COUNTERPOINT: Traditional project management isn’t suited to our industry; facilitative leadership is what really unlocks team potential.

Erin Vang, PMP

Like Tina, I started learning project management by managing some localization projects, getting really frustrated, inventing lots of wheels, and taking a lot longer to figure out basic tools than I care to admit. Believing there had to be a better way, I set out to learn project management properly, but the more I learned, the worse I got at doing it and the less I liked my job.

I went to PM conferences, I read books, I went through PMP training and certification, and I never stopped thinking, “Yeah, right. As if I would ever get away with any of this with my team!”  There was just no way that any software developers I’ve ever worked with would put up with that kind of bureaucracy or allow their creativity to be hampered by committing to detailed plans. But I kept trying.

Then I went to a class on facilitation, where ideas about how to serve groups by being neutral on the content while owning the group process sounded great, but once again I was thinking, “Yeah, right.” How could a localization project manager be neutral on the content? If an LPM doesn’t ride herd on every detail and make most of the decisions, disaster follows!

That’s when I had my epiphany. Where I was going wrong was by trying to be in control of things. In practice—especially in client-side localization project management—we’re often the only people in our organizations who care about and understand localization well enough to make decent decisions, so we end up taking charge. But in theory, a project manager is supposed to serve stakeholders, get decisions from them, and generally run things according to guidelines set by them. Somehow I needed to get my stakeholders to take control.

I found some possible answers in facilitative leadership, which is all about sharing control and optimizing processes to achieve fluidly evolving goals.

I decided to give it a try. I didn’t have much to lose—I hated my job and my team hated me. It’s not like I could make anything worse. So one day I abruptly let go of all control. I announced at the beginning of a much-dreaded project review meeting that I was going to be neutral about the projects and just serve the group, and if anyone caught me showing opinions or trying to take charge of anything, they should call me on it.

It worked. In the space of two hours the team went from avoiding structure to asking me for more structure. They took responsibility for the project’s problems, they started listening to each other and collaborating, and they proved me wrong about them. They were a good, talented team who wanted to work together better. They’d just had a lousy project manager.

I’ve never looked back. My teams and I are all a lot happier. My stakeholders are making educated decisions. My groups are making plans, committing to them, and sticking to their commitments. They’re raising red flags to me. When I stopped trying to control things, they stepped up.

Facilitative leadership is all about guiding your groups to work better together. Facilitative leadership puts people and communication ahead of process, empowering diverse kinds of players to learn from each other, to evolve process improvements, to discover innovation opportunities, and most importantly to design and build group agreements, commitments, and plans.

When you succeed at that—when you get the right agreements and commitments up front, and when you enable the people in your group to work together well—your group can succeed no matter how lousy you are at traditional project management.

Bottom line: if people are the key to your effort, then I think facilitative leadership is the key to your success.

For all we might talk about the promise and benefits of technology in this industry, the challenging and inspiring fact is that the most important work is done by people, now and in the foreseeable future. This is why it is crucial for localization project managers to maximize our facilitative leadership abilities, to bridge the cultural, technical, and stylistic gaps among the many participants, and to resolve wisely the inevitable conflicts between technical issues, market needs, and resource constraints.

Like Tina argues, it’s all a matter of proportion. Project management has its place, and I use some of the basic techniques like Gantt scheduling and budget spreadsheets all the time. If I could get my team to adhere to a responsibility assignment matrix, I’d be thrilled. I just think all those tools are primitive compared to facilitative leadership, which adapts to and exploits the best part of working in localization: the fascinating people who do it.

Localization and translation are almost always outsourced, and for many good reasons. Vendor management is therefore crucial to any localization or translation program, and it starts with vendor selection. Every aspect of vendor management—the financial and legal relationship, communications, project coordination, risk planning, and so on—will be easier if you start by taking the time to find the vendor or vendors that are best-suited for your needs. A huge number of companies is eager to have your business, most of them will bend over backwards to adapt their processes to your needs, and many of them are truly excellent. But one size does not fit all. The best possible vendor for one company might be a lousy fit for your company. If I had to get it down to one sentence, my advice would be this:

Don’t go by price, go by who understands your needs the best.

If you have time for more than one sentence, read on. The best vendor is the one whose questions make sense, whose warnings ring true, and whose projections seem realistic. Trust your gut on this, because like Dr. Spock used to tell parents, “You know more than you think you do.” How do you find the vendor or vendors who will pass that gut-feel test? Here are some tips. Are they selling what you need?

What do you need—translation, interpretation, localization, or internationalization?

There might be a few vendors who can do it all, but most of them specialize on one or two of these service. If you’re not sure which ones you need, here’s a quick rundown on the differences.

Translation, often abbreviated T9N (T, nine more letters, N), means converting text from one language to another. If you are a best-selling novelist in Scotland, your books are translated from British English into a gazillion other languages. Harry Potter is available in 67 languages including both simplified and traditional Chinese? They’re even translated into American English! That’s right–if you pick up a copy of the first book at Heathrow, enjoy it on your flight home, and then decide to pick up book two on your way out of O’Hare, you’re in for a surprise; Harry and his friends don’t speak the same language. I like the British English ones better, myself—I think it makes more sense when British schoolchildren use British colloquialisms—even though sometimes I don’t understand every detail. Did you know that when British kids revise, they’re studying for an exam? When American kids revise, they’re rewriting a paper!

Interpretation is when you do translation live, on the fly. Interpreters are the staffers who translate at meetings of world leaders or who work in the sound booths behind the scenes at the UN for all those diplomats wearing headsets. Interpretation is a special skill that goes beyond basic translation—interpreters have to work instantaneously without reference materials, and simultaneously, speaking in one language while listening in another. Interpreters also have to be attuned to the cultural and political nuances of a situation, and they typically have to be experts in (or bone up on) the subject matter at hand. You might think those world leaders are under incredible pressure, but the interpreters have it far worse! A friend told me about interpreting for an incredibly high-level meeting; she couldn’t tell me the details, but I was able to piece together that it was probably for the meeting between Presidents Bill Clinton and Jiang Zemin talking about nuclear weaponry. She explained that she worked in a tag-team of four interpreters working fifteen minutes at a time, because that’s the most stress anyone could handle. Another friend told about a much more pleasurable interpreting job, in which she learned all about wine-making while translating for a group of Spanish investors visiting wineries California.

Localization, often abbreviated L10N (L, ten more letters, N) takes translation several steps further. Localization means doing whatever it takes to adapt a product or service to the needs of a different local market. For example, if you make cell phones in the US and want to start selling them in Korea, you’ll need to do a lot more than translate the user interface into Korean. You need to change the radio to work on the Korean networks, which use a different protocol. You’ll also need to rejigger your software so that it can handle Hangul characters, and you’ll need to come up with a keyboard and text-input system that enables people to write text messages using Hangul characters with their thumbs. If you’re smart, you’ll also enable roman, Chinese, and Japanese character input, because lots of Korean customers need to be able to communicate in Chinese, Japanese, and English every day. And if you’ve done your market research, you know that the Korean market likes small, slick, colorful devices; models that sell well in the US are probably going to seem big and clunky in Korea. Localizing your product means addressing all of these barriers to local adoption.

Internationalization (I18N) is the global version of localization: it means doing whatever it takes to make your product or service work everywhere in the world, not just specific local markets. That could theoretically include translation into every known language, but in practice it means overcoming technical details that limit you to certain parts of the world. Internationalization is laying a good foundation for localization projects to follow. For software projects, it means doing things like adapting your code to handle the character sets needed by all the world’s major languages—for example, even if your product will only work in English for now, it ought to be able to work with strings (text) in any language so that you can translate your interface later but users can work with international character data now. You should make it possible to work with all the number, time, date, currency formats, and measurement systems used around the world. Your icons should be general enough to make sense around the world—and you might be surprised how images that seem obvious here can be confusing or even offensive elsewhere. It takes research and hard work to get it all right.

Do your business models match up? What are your business priorities and challenges?

Perhaps you’re releasing a new laptop around the world and need to translate the BIOS strings, the set-up pamphlets, and the customer support website. Your priorities are volume and turnaround time. You probably have millions of words and several dozen languages, and you need it all turned around in a few weeks. You’ll probably need to work with one of the huge, multinational vendors that can respond to that kind of volume and time pressure, who can put together a sophisticated workflow system for you. And you’d better write a contract that will enable you to enforce your expectations about turnaround time.

Perhaps you’ve made a defibrillator device that flight attendants can use when passengers have heart-attacks on board, and you’ve just negotiated a major sale to a French airline. Your priorities are quality and risk management. You probably only have a few thousand words and some graphics to get from English into a half dozen European languages, but this product is literally a matter of life and death—those translations and graphics have got to be right, and they have to be so simple that they’ll make sense to somebody who’s working under extreme pressure at an unfamiliar task.

Perhaps you’re involved in a major patent filing and you need to review hundreds of existing patents and patent applications around the world to ensure that your invention is unique and new. Your priorities are efficiency and legal expertise. Many of the seemingly-related filings are probably irrelevant, and you don’t need a full-blown exact translation of each one; you first need your vendor to sift quickly through the pile to help you determine which ones are possibly relevant, and then you need accurate, legally valid translations of that smaller pile. This situation is all about efficiency: anyone can machine-translate a CD full of text files and then put humans to work on the important files, but what about when you’re starting with a carton of printouts? And your device involves sophisticated molecular chemistry? And there’s a potential issue with exporting encryption? You need a vendor that has experience in handling these kinds of issues.

It’s always about price, but don’t go by the lowest bidder

It’s theoretically possible that there are some organizations out there who aren’t worried about costs, but I haven’t run into any of them yet. (If you’re at one of them, give me a call, please! I’d love to learn more.) For the rest of us, we’re under constant pressure to get more done at lower cost, so we have to pay a lot of attention to pricing.