Tag: learn

Bridging the Gap Between Software Development and Localization

by on Jul.28, 2011 , under facilitative leadership, localization, program management

Erin Vang moderates panel discussion on software l10n

Cross-posted from Lingoport.com

So, you’ve developed a new software application, and have high aspirations in terms of selling your application to a global audience. Now what? Problems often arise between developers, localization managers, and business managers due to perceived lack of support, time, and money.

This lack of understanding can lead to great frustration within the development tiers. Join us for an hour long online panel discussion and learn how some of the best known industry thought leaders are contributing to bridging the gap between software development and localization.

The panel features the following industry thought leaders and experts from the software development, content development, internationalization, and localization industries:

  • Val Swisher, Founder & CEO of Content Rules
  • Danica Brinton, Senior Director of International at Zynga
  • Dale Schultz, Globalization Test Architect at IBM
  • Edwin Hoogerbeets, Senior Internationalization Engineer at Palm
  • Adam Asnes, CEO & President of Lingoport

Online Panel Discussion: “Bridging the Gap Between Software Development and Localization”
Date and Times: Wednesday, August 3rd at 9:30am PT / 10:30am MT / 11:30am CT / 12:30pm ET
Registration: Register for free @ https://www1.gotomeeting.com/register/964415249
Where: Your desktop

Erin Vang, Owner of GlobalPragmatica will be facilitating the online panel discussion. Erin has over twenty years of expe­ri­ence in sta­tis­ti­cal soft­ware doc­u­men­ta­tion, qual­ity assur­ance, project man­age­ment, and local­iza­tion, most recently as Inter­na­tional Pro­gram Man­ager for the JMP Research and Devel­op­ment at SAS, and pre­vi­ously with Aba­cus Con­cepts and SYSTAT. She is currently designing a localization program for Dolby Laboratories.

This presentation is intended for technical managers, software engineers, test engineering managers, QA managers, internationalization and localization managers, technical writers, content developers, and anyone wanting to learn more on how to optimize their global software releases.

We’d love to hear from you. Please send any questions or topics you’d like to have discussed during this panel to Chris Raulf @ chris (at) lingoport.com.

Update 4 August 2011

The recording of our panel discussion is now available here.

Leave a Comment :, , , , , , , , , , , , more...

How to parse a tricky date string

by on Jul.28, 2010 , under JMP & JSL

Recently on LinkedIn, Asit Rairkar asked about how to parse a tricky date string into a numeric date column in JMP. He has date/time data as character data, but unfortunately it’s not formatted in one of the many date formats that JMP supports directly. He wrote:

I have found that informat does not work with all sorts of texted dates. e.g. I have had some tables with date codes as YYMMDDHHMMSS and I have had to manually seperate the 2 digits each and combine them again into YY/mm/dd hh:mm:ss format to feed in. Not sure if there is a better way to deal with this type of input.

Writing JSL to handle this situation is conceptually simple, but getting the JSL just right is tricky. The format JMP supports that comes closest to this format is “yyyy-mm-ddThh:mm:ss,” so that’s what I decided to work with, but overcoming the little differences between JMP’s format and Asit’s string takes some work. We have to doctor up the input string so that it matches the format JMP can handle. We’ll need to:

  1. change the two-digit years to four-digit
  2. add the “-” delimiter between year, month, and day
  3. add the “T” delimiter between date and time
  4. add the “:” delimiters between hours, minutes, and seconds

Once we’ve gotten the input string to match a JMP-supported format, we put that inside Num() as the Formula() for a new numeric column. We also have to specify one of the date/time formats for the column, and to keep things simple, I’ll just use the “yyyy-mm-ddThh:mm:ss” format again, but you could choose any format.

Here’s how it works

Suppose your data table looks like this:

You can generate my example by running this script:

dt = New Table( "tricky times",
  Add Rows( 4 ),
  New Column( "event",
    Character,
    Nominal,
    Set Values(
      {"Erin starts researching Asit's question", "Erin starts this blog post",
      "Erin wants a beer", "This blog post better be done"}
    )
  ),
  New Column( "when",
    Character,
    Nominal,
    Set Values( {"100726174324", "100728154315", "1007281730", "110728154315"} )
  )
)

So our first programming task is to convert a string like "100726174324" to a string like "2010-07-26T17:43:24", by performing the steps listed above. We could probably do this most efficiently with a clever pattern-match or regular expression statement, but both of those strategies present some disadvantages for a casual scripter:

  • they’re hard to learn, and it’s probably too much trouble given how seldom a casual scripter needs to do this sort of thing
  • they’re hard to read and decipher later—somebody who’s got a lot of practice at this kind of thing can write the patterns or regular expressions fairly easily and quickly, but figuring out a pattern or regular expression that someone else wrote (or that you yourself wrote a week ago) is much harder
  • they’re hard to debug
  • they’re hard to “borrow from” later on when you encounter a problem that’s slightly different

For these reasons, I’d rather solve this problem with a formula that is perhaps inefficient but is easy for me to read and easy for me to adapt later on. It won’t run as fast, but the time I really want to save is my own—I don’t care so much, in this case, if JMP has to work a little harder. So, let’s take it one step at a time.

1. change the two-digit years to four-digit

This is potentially tricky. Are all of the years in this century, e.g. 20-something? Or do we have a mix of centuries? If they’re all the same, it’s easy. We just Concat()enate a “20” in front of the two year digits we do have. I like the shorthand || operator better than the function Concat(). We get those two year digits by taking a Substr()ing of :when starting on the first character and continuing for two characters:

"20" || Substr( :when, 1, 2 )

If they’re a mixture of centuries, we’ll need to add some logic for guessing the correct century. Using a transition point is one way to do it. For example, if none of the dates are expected to be in the future or more than a hundred years in the past, we can safely assume that anytime the yy portion of the string is greater than the current year, we should prepend “19” rather than “20.” To do that, we need to compare the string’s yy, Substr( mydate, 1, 2 ), against today’s yy. But what’s today’s yy? Start by getting today, as a year: Year( Today() ) is the numeric value 10. Now convert that to a string with Char() so that we can use Substr() to grab just the last two characters:

Substr( Char( Year( Today() ) ), 3, 2 )

Now do the comparison inside an If(), and make the result "19" when yy is greater than the current year and "20" otherwise. Concat() that result onto the yy:

If( Substr( mydate, 1, 2 ) > Substr( Char( Year( Today() ) ), 3, 2 ),
  "19",
  "20"
) || Substr( mydate, 1, 2 )

Whew! Fortunately the next few steps are easy.

2. add the “-” delimiter between year, month, and day

We’ve already got the yyyy piece. Now we use Substr(:when, x, 2) a few more times with x being the first character of the mm and dd pieces. We insert a string "-" between each piece, sticking it all together with ||s:

 || "-" || Substr( :when, 3, 2 ) || "-" || Substr( :when, 5, 2 )

3. add the “T” delimiter between date and time

That’s easy:

|| "T" ||

4. add the “:” delimiters between hours, minutes, and seconds

Same old same old! Just more Substr() and || action.

Substr( :when, 7, 2 ) || ":"
|| Substr( :when, 9, 2 ) || ":"
|| Substr( :when, 11, 2 )

Put it all together!

Those four steps have produced a string formatted like "2010-07-26T17:43:24", and if we put all that inside Formula( Num( ) ) for a New Column command, we’ll be creating numeric date values.

New Column( "time",
  Format( "yyyy-mm-ddThh:mm:ss" ),
  Formula(
    Num(
      // convert what you have to something like "2010-07-26T17:43:24"
      // assume dates only in past, within last 100 years
      If( Substr( :when, 1, 2 ) > Substr( Char( Year( Today() ) ), 3, 2 ),
        "19",
        "20"
      ) || Substr( :when, 1, 2 ) || "-" || Substr( :when, 3, 2 )
        || "-" || Substr( :when, 5, 2 ) || "T" ||
      Substr( :when, 7, 2 ) || ":" || Substr( :when, 9, 2 )
        || ":" || Substr( :when, 11, 2 )
    )
  )
);

Now we have:

Notice that this technique is even forgiving of strings that are too short. I intentionally left off the ss part of a few of those strings, but since Substr(:when, 11, 2) just produced an empty string "", the formula still worked. That’s an advantage we’ll lose in the next strategy.

Uh-oh! There’s a problem in that last row! When I wrote my example time strings, I was thinking of 2011, but our algorithm above assumes that all data are from the current year or earlier, so that date got converted to 1911 instead. My event description needs improvement.

What if the dates are not in a data column?

Suppose the date value strings aren’t in a character column of a data table—suppose they’re just string values. In that case, we can use the In Format() function to convert them. The guts of it are still the same, but this time we’re parsing a string stored in a global called mydate instead of rows in a column.

mydate = "100726174324";
mydateNum=Informat(
  // convert the string to "2010-07-26T17:43:24",
  // assume dates only in past, within last 100 years
  If( Substr( mydate, 1, 2 ) > Substr( Char( Year( Today() ) ), 3, 2 ),
    "19",
    "20"
  ) || Substr( mydate, 1, 2 ) || "-" || Substr( mydate, 3, 2 ) || "-"
    || Substr( mydate, 5, 2 ) || "T" || Substr( mydate, 7, 2 ) || ":"
    || Substr( mydate, 9, 2 ) || ":" || Substr( mydate, 11, 2 ),
  "yyyy-mm-ddThh:mm:ss" // or another format
);

Running this script returns the numeric value 26Jul2010:17:43:24 and shows that in the log. Notice, however, that when mydate = "1007281730";, missing the ss part of the string, it doesn’t work, and we get a missing value. Our ugly hand-made parser is actually more forgiving than JMP’s In Format() command. But it’s not much better—if we were missing any other part of the string than the part at the end, we’d get mixed-up results.

What pesky date, time, or duration strings have vexed you?

The good folks at JMP keep adding support for more and more date/time/duration formats, but it seems like there’s a never-ending supply of crazy formats that analysts encounter. Typically the strings are coming into JMP from other programs and from data-streaming devices, but they might also arrive when peeling data off web pages or dealing with data entry performed by other people.

What are the crazy formats that you’ve had to crunch into numeric values in JMP?

What are the tricks you’ve developed for crunching them?

Please share your experiences in the Comments! I’ll try to answer any questions you leave there, too.

3 Comments :, , more...

How to hold better meetings

by on Jul.12, 2010 , under facilitative leadership, program management

Previously I wrote a response to Adriel Hampton’s thought-provoking blog post entitled “Five Reasons to Kill ‘The Meeting'” in which I argued why I think live meetings, preferably in person, are valuable, even though many of us hate a lot of them. Now I’m going to share some tips on how to make your meetings better.

I’m writing this primarily for people who run meetings, but most of these ideas can be used to good effect by mere “powerless” attendees. These are all classic facilitation concepts, and while a designated, trained facilitator will have advantages that attendees don’t, attendees can often speak up and “facilitate from their chair” with astonishing effectiveness, and in some groups, a peer will be far more effective than any authority figure.

What people hate most about meetings is feeling powerless.

Or ignored.

But it’s usually the same thing.

  • We all hate going to meetings where we’re talked at and nobody notices or cares if we fall asleep.
  • We all hate meetings where the decision has already been made, but nobody’s being up-front about that.
  • We all hate meetings where the people who need to hear the discussion aren’t in the room, or aren’t listening, or just don’t get it.
  • We all hate meetings where we know we’re going to have the same old fights and end up in the same old impasse, and nobody’s going to make a decision (or realize that their plan hasn’t been working and isn’t likely to).
  • We all hate meetings where only one point of view is important. I don’t really care if the CEO thinks this is the only way to save the company, if I know it can’t be done in the time and budget allowed, or if I know that the customers hate it when we do that, or if I know that’s the right thing to do but key stakeholders are too proud to accept a change in plans, or, or, or, or…

Meetings slow things down, and that’s good. (Sometimes.)

Central to many arguments about meetings is a premise that meetings slow things down. Certainly it’s true that many meetings are a waste of time for at least some if not all of the participants, and it’s not uncommon for people to have so many regularly-scheduled meetings that they effectively have only a one- or two-day work week. (More on that below.)

However, I question the premise that speeding things up is a good thing. The more important an outcome is, the more important I think it is to slow down and make sure it’s the right outcome.

“Go slow to go fast” is a facilitator’s mantra. It is far better to waste an hour in a meeting than to proceed with a plan that misses an important detail or a team that isn’t in full agreement.

A single team member who disagrees with the plan can sabotage an entire project. A good facilitator discovers who that person is and makes sure that person has a chance to voice their concerns. A good facilitator helps that person get the chance to explain what the others might not be considering.

Sometimes that person is just a nuisance. But even the troublemakers usually have useful points to make, even if you don’t like the way that they make their points.

When this person’s concerns are heard respectfully, and restated by others so that the person can be confident s/he was understood, then the group can weigh those concerns against the known constraints and competing concerns in a way that either incorporates those concerns or at least enables the person to go along with the plan. Even if the group reaches a different decision, if the dissenting concerns are acknowledged and weighed in a process that is transparent and is consistent with the group’s agreed-upon decision-making method, usually the dissentor(s) will be able to commit to the plan.

More on both of those ideas!

Transparent doesn’t mean public.

When I say that a group (or leader) needs to have a transparent process, that doesn’t necessarily mean that everybody is in on everything. It only means being clear and honest about how information will be explored and how decisions will be made. For example, a leader can say, “I want to get your feedback and ask for a show of hands on the different options today, and I will take that input to next week’s meeting with the directors, who will make a decision.” Most teams will accept that happily, but if they think they get to make the decision and then someone else does, they’ll be angry.

Transparency also requires following through on the stated process and being candid about any subsequent change of course.

Transparency and accountability means not pointing fingers at the team who tried to talk you out of it if it eventually turns out you were wrong. It might kill you to say it, but acknowledging that the team was right and you were wrong will buy you tremendous team loyalty—so much that I’d almost recommend doing that on purpose once. Almost!

Agree on (or at least announce) a decision-making method.

Decisions don’t have to be unanimous or even consensus or majority-rule. Many decision-making methods can work. The most important thing is to have one, and the next most important thing is to have group agreement or at least a candid announcement about what it is.

How do you decide how to decide? It depends on what’s at stake. Generally, the more say a team has in the decisions that affect them, and the more confident the team is that everyone on the team accepts the decisions, the more conscientious that team will be about executing on the decisions and being proactive about resolving issues that arise. The catch is that more say takes longer.

Here are some valid decision-making methods, from fastest and least engaging to slowest and most engaging:

  1. Leader decides and announces.
  2. Leader seeks input, then decides.
  3. Majority rule (discuss and vote).
  4. Consensus (keep at it until most people agree and those who disagree are satisfied that their concerns have been addressed or at least acknowledged).
  5. Unanimous (keep at it until everybody can agree with the plan).

Having a fallback is helpful. For example, “We want to reach consensus, but if we cannot reach consensus by the end of the week, then we’ll take a vote on Monday.” Or, “If the team can reach a unanimous agreement, that will be the plan, but otherwise I’ll make a decision based on our discussion today.”

When is something important enough to justify a meeting?

What is the value of a good decision, or an effective plan, or a group that agrees enough with the plan to remain committed to it? What is the cost of not reaching these? What is the risk of proceeding without certainty that everyone is onboard with the plan? That is the value of the meeting. The cost of the meeting is the number of people in the room, times the number of hours, times the hourly wage, plus any other costs such as travel, room rental, web-meeting fees, etc. You might multiply the number of hours by the number of people by an average cost of $50 per staff member or manager and $100 per executive or hired consultant. If the value is higher than the cost, you should have a meeting.

It’s often hard to estimate value objectively, but here are some subjective criteria that are probably good enough. Ask yourself these questions about the outcome:

  • Will more than a few people spend more than a few weeks working on it?
  • Will a customer ever see it?
  • Could a bad result lead to a lawsuit?
  • Is there anyone affected by it who might be silently disagreeing?
  • Is anyone’s influence out of proportion to his or her competence and credibility? (For example, a CEO who doesn’t understand crucial technical details, or a chief engineer who doesn’t understand business constraints, or a sales manager who is purely commission-driven?)
  • Are you worried about what you don’t know, or what you might not realize you need to know?

If your answers to any of these questions is yes, then it’s worthwhile to have a meeting.

Minimize the intrusion of meetings on the work week.

Meetings burn time, and not just the duration of the meeting but also the time it takes to get to and from the meeting and time spent with meeting logistics like calendar management, preparation, follow-up, and rescheduling other commitments. Worse, meetings have an interruption cost. If my work requires focused concentration for several hours at a time, then a meeting that runs from 10 to 11 am pretty much destroys my 9 am to lunchtime shift. The most I’ll be able to get done from 9 to 10 and 11 to 12 is handle some email and maybe an expense report or travel reservation. There is no way I’ll be able to debug and fix some code, or write a proposal, or intervene in a staff problem, or persuade my manager about something. If I have another meeting from 2 to 3, then my afternoon is also shot, and my most important responsibilities—the things I’m paid to do—will be postponed another day, or I’ll be forced to put in some overtime that night.

Minimize how your meetings intrude on the work week. Some easy ways to start:

Have designated meeting days.

If you can get all of a team’s meetings out of the way on Tuesdays, that leaves the rest of the week free for focused work. Mondays and Fridays tend to suffer from higher numbers of absences because of people taking long weekends, so Tuesday, Wednesday, and Thursday are better. Ask yourself whether your team benefits from having a break from work mid-week (making Wednesday a good day to meet) or from having several days in a row available to focus (making Tuesday or Thursday better). More important than which day(s) you choose, though, is that you choose, and you enforce the no-meetings-days goal as much as possible.

Have the shortest effective meeting.

Go slow to go fast—make sure everybody’s voice is heard when it’s important—but don’t waste time with unnecessary agenda items. Don’t hesitate to adjourn early. Offer breaks when people get restless, start yawning, or are clearly needing to check their messages. Start on time no matter who’s late, and never go over the allotted time without group agreement and permission for some people to leave. Don’t go overtime if it would deprive people who need to leave of their chance to be heard.

State the agenda and goals in advance.

Nothing is more frustrating than having to go to a meeting whose purpose is unclear, or worse, where some people might have (or seem to have) a hidden agenda. Send out a written agenda, with time allotments for each topic if possible, and with clearly-stated goals. The goals should be measurable and believable, and they should be nouns—for example, “a list of issues needing further exploration” or “a decision about how to proceed” or “a preliminary schedule with major milestones and goal dates.” Ask yourself how the group will know if they met the goal(s) of the meeting.

At the beginning of the meeting, check with the room: “Are these the right goals? Can we do this today? Am I missing something important?”

At the end of the meeting, even if you think you know the answer, ask the room questions like, “Did we meet this goal? Do we need another meeting? Is there anything for next week’s agenda?”

Protect your team from the risks of vague agenda items.

Your agenda might be vague or contain a vague element. If so, take steps to promote confidence that those vague areas will be handled efficiently and nobody will be ambushed by surprises.

For example, if you need to go around the room to get status reports, have everybody remain standing so that nobody will drone on and on. Add a fun element, such as “What progress did you make, is there anything you’re stuck on, and what’s the next movie you want to see?” (If you do something like this, include the list of movies in your meeting notes.)

Sometimes issues arise that might feel like an ambush to some people in the room. Do what you can to make people comfortable raising those hot-button issues, because sweeping them under the rug is never better, but take steps to protect people from unpleasant surprises becoming nightmare scenarios. For example, you might ask, “Does anybody need some time to research this before we discuss what to do next? Is there anybody else that we’ll need to include in this discussion?” Often the best course will be to allow time right away for the basics to be laid out, let people ask any immediate questions, and then schedule further discussion after people have had some time to ponder and research.

If the circumstances demand an immediate decision, do your best to let people be heard, to record objections and unsettled questions, and then take responsibility for the way you proceed. If you must make an executive decision, be transparent about that. Be honest that you’re making a judgment call with incomplete information, and remain accountable for it in future. Do what you can to revisit the unsettled points when time allows. If possible, plan ways to revise the decision as better information becomes available. If your decision turns out badly, be candid about that, too, and acknowledge that some people did raise pertinent objections.

Follow up with brief meeting notes.

Brief is the key here. All you really need is a record of the decisions and agreements, a list of points needing followup, an acknowledgment of any important disagreements or what have you, and a list of open action items with names and goal dates. Some action items might be incomplete, with names, dates, or other details to be determined. If you are ready to include the next meeting’s agenda and logistical details, great.

Always provide a method for people to correct your mistakes and omissions. For example, “Please REPLY ALL with errata and addenda. Have I missed anything important?”

Avoid detailed summaries of who discussed what or disagreed why; you can only lose at this game. Just record what was agreed and decided, and if appropriate also record the points that were left unaddressed, or the objections that were raised, or the points needing further discussion, without commentary. Ask yourself whether anybody who was in the room will be surprised by your notes or would state anything differently. Ask yourself whether somebody who missed the meeting will learn what they need to know.

Sometimes it’s helpful to consult with the room about what should go in the notes, as a way of preventing misunderstanding later on, or even as a way to bring discussion back into focus. For example, after a lengthy discussion or an uneasy resolution, you might ask questions like, “How should I capture this for the notes? Can somebody restate that for me? Does anybody disagree with this proposal? Are there any action items to go with that?”

Overtime costs a lot more than time-and-a-half.

Be especially careful about scheduling meetings that will force people into working overtime. Even if it doesn’t bring a direct labor cost increase, it usually brings a psychological cost increase.

Speaking for myself, I don’t think twice about working overtime to make up for my own poor decisions, for example, or to solve a problem that I just can’t wrap my brain around during the day. But I resent being forced to work overtime because somebody else wasted my time or made a poor decision. If I have concert tickets or a family obligation or am not feeling well, I resent it even more.

I will forgive my colleagues and take one for the team occasionally, and I’ll gladly go the extra mile when it’s the difference between success and failure for something I believe in. (And now that I’m a self-employed consultant who bills by the hour, I am extremely flexible about when those hours need to happen.) But if any work situation (or a social situation, for that matter) creates a pattern of abusing my time, sooner or later I will resent it. And that resentment will cost the organization in terms of my reduced commitment, my less-than-stellar attitude, my frayed nerves, my depressed health, and eventually perhaps even my departure. I won’t sabotage a project—I’m just not wired that way— but you’d better believe it that if you push some people far enough, they will sabotage your project. Maybe not consciously, maybe not deliberately, but they will find ways to undermine even their own success to get back at someone who has done them wrong.

Do you feel the same way? Do your colleagues?

I have some beliefs because of my experiences. You have had different experiences and reached different conclusions. I would love to hear from you!

What am I missing?

What have I gotten wrong?

What do you see differently?

What did I say that surprised you? Do you think I might be right, at least for some people or situations?

What do you think would surprise me? Can you tell me a story from your experiences that would help me understand your point?

1 Comment :, , , , more...

Point/Counterpoint: Let the interoffice games begin!

by on Nov.06, 2009 , under facilitative leadership, program management

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.

1 Comment :, , , , , more...

Getting started in localization project management

by on Jan.16, 2009 , under localization

Congratulations, you’re in charge of localization! …So now what?!

It’s bizarre but not all that uncommon that organizations will suddenly realize that they could market their products or services outside the US and Canada, and just as suddenly they pick somebody who doesn’t seem all that busy and put them in charge.
So if you’re the lucky new localization project manager, congratulations! But what do you do next? Or if you’re the executive who realizes this is crazy, what’s your alternative? How do you convince everyone else that localization is a nontrivial undertaking?

The good news

First, the good news: Some of today’s top experts in localization started exactly this way. I recently led an industry conference where the question kept coming up: How did you get into this field? So finally I asked everybody in the room to describe their background and how they ended up involved in localization. Only a handful had a background in languages, and only one had formal training in localization, translation, or globalization. Yet all were highly successful professionals. My best guess is that the field attracts talent and filters out mediocrity, perhaps because its challenges are layered and exotic (and fun!).

The bad news

Now the bad news: Localization is incredibly complex, and most people spend years at it only to discover they’re still just scratching the surface. Moreover, running a successful localization program often also requires educating the rest of the organization about how international market expectations differ, and advocating why those differences matter. Localization could have a bigger effect on short—and long-term revenue growth than any other activity in the organization, yet many executives will be looking at it as a giant money-sucking monster.

So where do you start? I have three tips.

  1. Find a good vendor.
  2. Lead with your strengths.
  3. Get help with the rest.

Number one, you’re going to need a good vendor—or maybe several of them—no matter what you do. Localization is almost always outsourced, and for many good reasons. Vendor management is a whole discipline in itself, but if I had to get it down to one sentence, it would be this: “Don’t go by price, go by who understands your needs the best.” 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.”

Number two, lead with your strengths. If you know project management and development process, then take charge of the logistics, ride herd on your budgets and schedules, and be sure to under-promise and over-deliver. Do that and you’ll earn upper management’s confidence, and they’ll listen to you when you ask for resources. If you know the product or service inside and out, then share that knowledge with your translation team. Get involved in teaching it to them and answering their questions. Do that, and you’ll earn your team’s confidence, and they’ll have your back when challenges arise. If you’re a good people person, then put your energy into helping your group become a great team. Do that, and they’ll accomplish astonishing things.

Number three, get help. Nobody can learn it all, nobody can do it all, and faking it doesn’t work out as a strategy long term. To develop wise strategies and effective tactics in localization by yourself, you would need to become conversant in many or all of the following in addition to all the technical details of your product or service:

  • Finance
  • Contract administration
  • Project management
  • Linguistics
  • Procurement and vendor management
  • Local market requirements
  • Global market research
  • Global business practices and work cultures
  • Terminology management
  • Content management
  • Product technology and development processes
  • Desktop publishing technology and trends
  • Quality assurance
  • Translation memory, alignment, and leverage (reusability)
  • Computer-assisted translation technology
  • Virtual, distributed team leadership
  • Facilitation and conflict resolution
  • Translation workflow
  • Localization best practices and industry trends
  • Organizational politics
And on and on…

Conclusion

Obviously it’s ridiculous to think that anyone could develop all these strengths during their first project cycle, or for that matter their first five years, yet all will come into play, and probably sooner rather than later. So lead with your strengths, get all the training you can, and seek the help you deserve.

We’re here to help

GlobalPragmatica offers facilitative leadership with domain expertise in localization, internationalization, and project and program management. GlobalPragmatica provides pragmatic guidance to help a client-side organization develop and achieve its global vision through sustainable strategies, effective tactics, and committed teams. GlobalPragmatica also helps companies in the localization, translation, project management, and facilitation domains work better and smarter with their clients.

Learn more at http://globalpragmatica.com or email us for a no-obligation consultation at info@globalpragmatica.com.

This article also appeared at GlobalPragmatica partner ENLASO’s Language Technology Center. For more information on how ENLASO can assist you with all of your localization needs, see http://www.translate.com.

Leave a Comment :, , , , , , , , , more...

Artwork

Global Pragmatica's artwork includes paintings by Zsuzsi Saper and digital photographs by Erin Vang. Further notes on specific pieces of art are given at the bottom of pages in which they appear. All artwork is copyright 2009–2010 by Global Pragmatica LLC®. All rights reserved worldwide.

© 2009-14 Global Pragmatica LLC®

All content © 2009-14 by Global Pragmatica LLC®. All rights reserved worldwide.

Global Pragmatica LLC® is a registered trademark of Global Pragmatica LLC. The ® symbol indicates USA trademark registration.

Contact Global Pragmatica LLC®

info@globalpragmatica.com
+1 415.997.9671
Oakland, CA 94611