When it absolutely positively has to be there overnight...

FedEx Express van driving in Delhi, India., via: http://news.van.fedex.com/node/439

I never really thought about what the boom in IT outsourcing, outsourced product development and manufacturing is doing to business logistic and support companies in India and China. However, my wife sent me a link recently that really punctuated the fact that the old adage holds true: One of the best ways to make money on a gold-rush is to sell tools and services to the miners...

Federal Express (FedEx) has a FedEx India web site that is clearly seeking to capitalize on the trade between India and the US. Among their other activities, they're sponsoring an India Trade Mission, wherein they're hosting US executives on a one-week fact finding and networking trip through New Delhi, Hyderabad, and Mumbai. Pretty cool stuff they're doing, in partnership with the U.S. Commercial Service.

In addition to this Trade Mission, they have a great fact sheet on India, that might be useful for anyone starting to do business there. If nothing else, it's entertaining to see what a different industry highlights about the Indian economy.

And of course, they will ship stuff to India for you, which is a far cry easier than the no-name shipping company I used several years back to get bulky storage appliances through customs and into my labs in Pune.


Best Practice - Get to know your trade organizations

This is a quick post with some reference links to outsourcing trade associations. These organizations generally have the job of "selling" India, Russia, China, etc. I've worked indirectly with both RUSSOFT and NASSCOM, and find them to be good organizations, though I'll offer the caveat that their job is to sell prospects on the quality and scale of their respective countries. They're not necessarily in the business of offering objective measured advice on where you should site an offshore team.

RUSSOFT: (Russian Software Developers Association)
RUSSOFT Association is the nation wide association of the most technically competent software developing companies from Russia, Byelorussia and Ukraine. By joining forces under the leadership of RUSSOFT we are able to provide customers with a range of comprehensive solutions and IT services. (their blurb about themselves.)

NASSCOM: (National (sic) Association of Software and Service Companies)
NASSCOM® is the premier trade body and the chamber of commerce of the IT-BPO industry in India. NASSCOM is a global trade body with more than 1200 members, of which over 250 are global companies from across US, UK, EU and A-Pac. NASSCOM's member and associate member companies are broadly in the business of Services, Products, IT Infrastructure Management, R&D services, E-commerce & web services, Engineering services offshoring and Animation and gaming. NASSCOM’s membership base constitutes over 95% of the industry revenues in India and employs over 2 million professionals. (their blurb about themselves.)

Ministry of Commerce, People's Republic of China:
China takes a slightly different approach to the same set of issues that NASSCOM and RUSSOFT face. Remembering that China's private sector is, well, not really private, trade development is a government issue. Their Ministry of Commerce has a 14-part mission statement. Here's a flavor:
To study on, put forth and implement multilateral and bilateral trade and economic cooperation policies, be responsible for multilateral and bilateral negotiations on trade and economic issues, coordinate domestic positions in negotiating with foreign parties, and to sign the relevant documents and monitor their implementation. (from Item %6 of their mission statement.)

Other countries will have similar trade organizations, so where ever you outsource, get to know the trade organization.

Take their propaganda with a grain of salt, but these organizations can be powerful allies in ensuring a good business climate, in ensuring education of engineering and IT talent, and in generally educating you about the place where you send some of your company's work.


Indian English, or "verbing nouns"

Frequently through the last several years of my career I've been confronted by US engineers (the "retained staff" in major outsourcing endeavors) who wanted to give voice to complaints about their offshore cohorts in India.

Typically, the complaint has been something along the lines of "these engineers are not good at what they do." Whether the complaints were with or without merit, the focal points and exemplars were often communication skills, particularly in written English.

I'll be the first to admit that written English skills are critical to success in a global team setting.

However, I'd like to point out that there are some common usages that might seem odd to a reader in Chicago, but may be perfectly normal to a writer in Chennai. And these seemingly odd usage patterns don't necessarily indicate either low comprehension of written English, poor command of the English language, or low levels of skills and brainpower.

I've written before about the pervasive idiomatic language that seeps into business correspondence and writing. (...it's an old post, but if you're a new reader to this blog, it's worth taking a look at.)

If you're an American writing to a person or a team of people somewhere else on the planet where U.S. English (and all it's concomitant idiom) is not the first language, you need to carefully remove this idiom from your writing, or risk being misunderstood.

It's obvious but not necessarily a "given" that this applies in the other direction. For instance, by easy way of example, members of the Commonwealth of Nations may want to skip the cricket references.

Aside from idiom, there are other usage patterns that are problematic in global teams. I've recently started paying attention words and expressions that are not well understood or accepted in US Business English. This is a short list (transcribed off a corner of my white board) but should serve to illustrate the point, and hopefully to generate some comments or e-mail. I'll add words to this as I have them pointed out to me.

In Indian English, I've frequently seen phrases like:
  • The upgradation of the server. Upgradation isn't going to be found in the Webster's Collegiate Dictionary, but you will find it in a Dictionary of Indian English. It is used consistently to mean the past tense of the verb To Upgrade.
  • The updation of the system. Similar usage to upgradation.
If you think about it, both of these represent an attempt to apply a logical rule to the English language. In other similar words, it's normal to add "ation" on the end to change the form of the word. For instance, "to manifest" becomes "manifestation", with the noun form "manifest" representing a slightly different meaning now. In a famous Calvin and Hobbes comic strip, Calvin referred to this as "verbing nouns." I'd link to the strip in question, but I'm afraid of the copyright police...

Someone recently asserted to me that in Indian business English the words deployment, installation, and implementation were all used synonymously. That may be true, but on reflection, I don't believe that's a trait of Indian English, as I've seen similar kinds of problems occur with text written by studied practitioners and native speakers of US and British English. (As an aside to this issue, I'll say that the particular word chosen for deployment / installation / implementation is less important than consistent use of that word. Many professional writers will develop a "style guide" for a given topic. In it, they'll define what word or set of words they will consistently use to describe a single instance of a particular piece of technology, or multiple instances, or the physical act of making such an instance come into existence. In this case, again it's not the word, but the consistent application of the word. A glossary helps too.)

  • Another bit of Indian English that I found odd several years back was the phrase "do the needful." It is used in context thus: "We understand that this module must be completely tested by 08:00 EDT tomorrow. We will do the needful." It may sound quaint to Americans, but it makes sense if you think of it as a more stylistic way of saying "We're on it, dude."
These are just a few examples off the top of my head. Some of the language differences between Indian English and US English are idiomatic in nature. Some are attempts to extrapolate rules where common usage dictates that the rules don't really apply. Some are common traits of all people who speak and write in English.

Here's the best practice to derive from this:
  • If you're an American, remember that your global peers probably speak English as a second or third language. Cut them some slack. Don't presume that poor grammar or punctuation directly correlates to poor intellect or engineering skills.
    • Don't equate using the wrong word with not being smart. I grew up in the South of the United States, and went to public school. I'm a pretty smart guy, but for crying out loud, I was TAUGHT the wrong words for stuff.
  • If you're British, or if you grew up in the Commonwealth, you're probably used to your language being butchered. But remember, if you spell color with a u, we're going to resent you for it.
  • And if you're Indian, or Chinese, or Russian, or if your from any other country where English is not the native language, and if you've somehow managed to learn English to a level of fluency that allows you to conduct business and engineering in English, kudos!
    • You should be proud of that accomplishment.
    • But remember, every interaction you have with your global peers is a "selling" and a "teaching" event.
    • Try to mirror the language patterns of the people you work with. Use MS Word's grammar checker, with the locale set to US English. Avoid colloquial phrases, and request the same of your peers, where ever they are on the planet.
    • Use simple, precise language, and make it acceptable and safe for people to question your usage.
  • What ever language you use, decompose the problem space you work in, and come up with a glossary of common terms and usage. It will make communicating (amongst yourselves and with global teams) much easier and more precise.
  • What ever language you use for business, recognize that there are variants and dialects, and that your interpretation of what seems like a simple and obvious phrase may differ from your peer's, because of where they live, where they grew up, or where they studied the language. Be aware of this, talk about it, and avoid the trap of confusing one another with what seem like simple and obvious phrases.
Yea verily I vouchsafe these steps will easify your endeavors.


Lakhs and Crores

I was recently doing some research for my book, trying to find out the number of annual college graduates from a particular university in India. I was scanning quickly through on-line fact sheets, and entering numbers into a spreadsheet. Even though I know better, I fell into the Lakh and Crore trap, and because of Indian system of comma notation in numbers, I wrote everything down with an extra zero. It drove home the point that what I'm about to write is a useful thing to know, and that even if you know it, it's important to remind yourself of it periodically.

In case you don't know, India (and Pakistan, Bangladesh, Nepal, Myanmar and Sri Lanka) doesn't traditionally use the words "million" and "billion" to describe 106 and 109 respectively.

Instead, they use Lakhs and Crores to talk about big numbers. One Lakh is one hundred thousand, or 105. They write One Lakh like this:
  • 1,00,000. (note where the commas are)
If you're not careful, you might read that, look at the number of commas rather than the number of zeros, and think it is one million.

Crores are even tougher. A Crore is 10 million, or 107. They write One Crore like this:
  • 1,00,00,000. (again, note the commas)

As always, Wikipedia has a very informative article on this topic. For outsourcing professionals, this is worth understanding, both to grok what's going on when or if you read an Indian newspaper, and to avoid potential errors as you negotiate rates, review invoices, etc.


Blogging about blogging

This blog, Inside Outsource, has recently hit a milestone, wherein I've started getting hits and comments from people I've never met before. Given that I've done very little to publicize the existence of this endeavor, that's a very cool thing! It means that word of mouth is catching up with the content that I've been trying to provide.

If you're new to reading Inside Outsource, welcome. Look back through the archives, and I think you'll find some good, interesting, useful stuff. You may not agree with everything I say, but even if you disagree with my conclusions or my approach, I love a good debate. So please use the comments (or the e-mail feature) to let me know what you think!

Also, for anyone with an opinion on these matters:
  1. I'm in search of a new tag line for this blog. It used to be "A guide to making software on a small planet." My original intent was to explore topics specifically related to offshore product development. But my interests are more wide ranging than that, so the blog has become about globalization in general. If you have any great ideas about the tag line, leave a comment or e-mail me!
  2. I'm thinking about leaving Blogger and hosting this blog along with my commercial endeavors over on www.isosconsulting.com. Anyone have any opinions about the ease of use, feature capabilities, or general goodness of any of the alternative blogging packages like Wordpress, or Pixelpost, or Movable Type?
Thanks in advance for any thoughts, and welcome to all the new readers!


Best Practice - Go-to-Market partnerships

A vendor recently asked me how they could move up the value chain, in an "out of the box" kind of way.

My short answer to any vendors who read my blog: Help your clients sell their stuff in India (or where ever your delivery centers happen to be).

One thing I look for when I evaluate a vendor for my FastRFP portfolio service is something I call "Value-Added Partnership Capabilities."

Few of the service providers I've looked at through the years think this way, so it's clearly "out of the box." But, as India shifts from "labor arbitrage center" to "global economic superpower" over the next decade, ISVs (and other US enterprises) will eventually figure out that there's money to be made in India, selling what ever product it is that their ITO and OPD partners help them produce.

Imagine how they'd view their ITO and OPD services if their vendor signed up to develop India as a sales territory, and signed on with a sales quota!

If an enterprise has a 20 person development team with a vendor in India, that probably represents around $1M annually in cost to them. If the same vendor signed up for a $1M sales number, it would allow the enterprise to have a balance-sheet neutral development center.

If the vendor developed India into an even larger sales territory, they could potentially become a profit center for the enterprise. At which point it will be in the enterprise's economic best interest not only to stay with the vendor (rather than leaving for another cheaper service provider), but also to find new work for them.

You could even set the deal up in such a way that any excess over the $1M mark would automatically result in new headcount (rather than profit taking) for the vendor, so the whole endeavor became a self-funding development or service delivery franchise.

To the best of my knowledge, no one has built this model in India yet. The first company who can do this will potentially change the ITO and OPD landscape.


Huge news - Indian salary increases moderate

It seems that the long predicted flattening of India's IT salary bubble is finally happening. I just read this in the Indian Times.

EDS is giving an average increment of only 8 per cent to 10 per cent this year, substantially lower than the 18-20 per cent it gave last year.
‘‘Indian companies have so far been effecting unsustainable salary increments. It has clearly hit a correction mode this year,’’ says B S Murthy, CEO of hiring firm Human Capital. Wipro’s average salary increments are expected to be in the range of 8 per cent to 10 per cent against 12-14 per cent last year.

This is huge news. If you don't already know the scoop on IT salaries in India, here's the recent trends for average IT salary increases (cobbled together from a bunch of different reports):

To put this in perspective, if you were a college grad working in India in 2000, and you landed a job with a base salary of $4000, and you experienced "average" wage increases each year, you'd now be making a bit over $30,000 a year.


Outsourcing Help Desk Operations

To paraphrase a recent question from the LinkedIn Outsourcing forum:

Does outsourcing Help Desk Operations help or hurt the customer experience?

My answer to this either / or question is "yes."

I recently had the opportunity to address this problem in practice, and I laid out a back-of-the-napkin strategy for outsourcing an enterprise's help desk operations.

There were three key points of the strategy.

  • The first was to apply the "Pareto principle" and find the 20% of technical issues that resulted in 80% of the calls. Those would be delivered as "canned answers" on which the new offshore staff could be trained.
  • The second point was to build a well designed, well documented and well tested escalation mechanism back to the retained staff, to handle the other 20% of the calls. This is classic "Level 1 - Level 2/3" technical or customer support.
  • The final and most critical element of the strategy was to put a feedback mechanism in place that allowed users (i.e. customers) to rate their experience. I firmly believe that customer feedback is critical in operations like this.

    Ask your customers if they are happy with the transaction! If they couldn't understand the person on the other end of the phone, you need to know that. Then you need to do something about it. And lastly you need to let your customers know that you listen, and that you take corrective action if and when they point out a problem.
(I'll add the caveat that the customer is not ALWAYS right... This article provides a great (and very unconventional) riff on the old chestnut "the customer is always right.")

If you do these three things, you'll probably have no significant long-term change in your customer satisfaction. In some instances, simply by putting some process in place, and providing a feedback mechanism, you'll produce a slightly better customer experience. That's the help part of my answer. Simply by preparing to outsource, and managing it professionally, you'll tighten up that part of your business, and put metrics and targets in place for customer satisfaction.

If you fail to do at minimum these three things, you'll put your customers through hell, and they will suffer and view your efforts as "cheap" rather than "good." That's the hurt part of my answer above.

The feedback loop is the most important of these steps. No matter what business you're in, I'm betting that Customer Satisfaction is core to your business. As a general rule, you don't want to source away core business functions. If you fail to do these three things, your customer satisfaction will be in the hands of your outsourced service provider -- your vendor. That's dangerous...

So routinize your responses, test your escalation system, and sample your customers... If you give them a way to complain about bad service, they will feel like they're part of the solution, not simply victimized by the problem.

India and Taiwan produce outsourcing billionaires

India Times has a great article on the personal wealth created by some of the top outsourcing companies. None of these guys rival Bill Gates, but $12B US is nothing to sneeze at...

Azim Hasham Premji is the richest outsourcing billionaires with a net worth of $12.7 billion. Premiji heads Wipro, a provider of integrated business, technology and process solutions. The software services outsourcing company acquired a business process outsourcing arm in 2002.

A graduate in Electrical Engineering from Stanford University, US, Premji took on the mantle at Wipro at the age of 21, after the sudden demise of his father in 1966.

Under his leadership, the fledgling $2 million-hydrogenated cooking fat company has today grown into a $5 billion IT services giant with customers across the globe.



Translation, i18n and L10n

The task of turning software in one language into software in another language is something that all but the biggest companies outsource.

I've often thought that this is a great "wedge" issue to use with American engineers who are reluctant participants in outsourcing. It's a good, non-controversial issue to discuss because no matter what strategic yard-stick you use, it's unlikely that you'd make a strong case for insourcing translation or the translation related engineering services of localization and internationalization.

Through the years, I've had to put a lot of thought into these issues. I have been involved in internationalization of several software products and web sites, and I have attempted to simultaneously ship multiple releases of one particular product that was localized into 14 languages. I have always outsourced the translation, and have been involved with a variety of hybrid sourcing arrangements around internationalization and localization.

I was speaking with someone about this recently, and the framework I use to understand and break down this space was useful enough in that conversation to warrant a blog post all on its own. Hence the tower of Babel above, and my attempts to debabelize this messy space.

But before I get into the specifics of my thought-model, it's worth explaining i18n and L10n, in case some readers don't know about these abbreviations.

As always, Wikipedia has a good informative post on the topic. I quote here:

Due to their length, the terms are frequently abbreviated to i18n (where 18 stands for the number of letters between the i and the n in internationalization and localization, a usage coined at DEC in the 1970s or 80s) and L10n respectively. The capital L on L10n helps to distinguish it from the lowercase i in i18n.

As an editorial aside, I'll say that I think these are silly abbreviations. They usually require a long conversational preface in order to use them in any but the most geeky circles. But nonetheless, they are commonly used. To make my point that these are silly, I've tried to coin other similar alpha-numeric abbreviations, but unfortunately mine never caught on:
  • p2l for perl
  • j2a for java
  • m0e for me
Anyway, now that you know what these abbreviations stand for, I'll describe my simple mental model.

Given that most of my work on localized software products was on the quality assurance side, it's no surprise that my model refers to the classes or kinds of problems or defects you're likely to see with localized software.

The first is the hardest to diagnose and fix, though the least severe from a software engineering perspective. These are "translation" bugs. Software engineers typically view language as, well, language. It's a rule-based symbolic representation of abstract and concrete ideas. To many in my trade, English, Hindi and C++ are thought of as roughly equivalent.

But computer languages and human languages aren't even close to equivalent. Human languages are infinitely more complex and nuanced. And while we'd all like to believe that "Babelfish" does a good job, the truth is that machine translation is in its infancy, and that real humans are required to translate any given sentence into a new language with any hope of retaining situational context. This is all a long-winded way of saying that translation is art, not science.

This has been famously discussed with such apocryphal blunders as:Examples of this kind of blunder have found their way into our urban legend lexicon:
  • The Chevy Nova, which translated as the "It doesn't go!" in Spanish markets.
  • The Ford Pinto, which had a euphemistic translation of "very small male reproductive organs" in Brazil.
  • The Schweppes Tonic Water ad in Italy that translated their flagship product as "Schweppes Toilet Water."
  • Or even JFK's famous "I am a jelly donut" speech.

These profound and obvious translation errors are easy to find and easy to fix. While these examples are mostly fiction, it does sometimes happen that translators just straight-out mess up, and select the wrong word, the wrong syntax, or in any of a hundred other ways really get it wrong. Picking the wrong word for something just means you've got a weak translator with poor grammar or idiomatic vocabulary skills in either the source or the target language.

But because translation is art it is subject to the whims of fancy. And because of this, a second sub category of very nuanced "possible errors" results. That is, two different translators will often translate the same sentence differently. This results in cosmetic defects wherein the reader or end-user just doesn't like the way something was translated. These defects are difficult to discover, because you have to involve a large audience of native-language testers or users, and they're hard to fix, because they're about art and opinion. I've had to play King Solomon in many arguments between my user community (or sales teams) and my translators, where the "baby" in question was the translator's decision on a particular phrase or passage.

Anyway, that gives us Category One: Artful Translation Bugs.

The second group of issues has to do more with on-screen display. In my experience and to my way of thinking, this is mostly about software graphical user interfaces, and it's mostly the result of static layout and bad software design. In lay terms, graphical user interfaces (GUIs) are built by telling the computer to draw a window, and to put stuff in it or on it. Designers like to control the stuff, so they tell the computer how big to make buttons, where to put them, what they should look like, etc. The designers typically try to make their screens "pretty" in what ever version of pretty is popular in that particular shop on that particular day.

The trouble comes when you write text on the top of your pretty button. For instance, you might have a "Go" button on your application or in your web page. You might constrain the software to use Courier font, size 12 (a popular choice with designers!). Then, you might tell the application that the Go button needs to be 25 pixels wide and 18 pixels tall. It works great, and it looks great, and the word "Go" just fits. Then, you decide this product would sell well in Germany, and you localize it into German. The "Go" in the "Go" button gets translated, and the whole thing now becomes the "Gehen Sie" button. "Gehen Sie" doesn't fit onto your 25X18 button. Depending on the application, maybe you have a "Ge" button, or possibly a "ie" button, both of which are meaningless. Or maybe "Gehen Sie" gets written past the boundaries of your button, over the top of some other text or object. Either way, the software suffers, and it's a bad defect. This problem gets even worse if you localize to languages that uses graphemes, phonemes, morphemes or ideograms instead of a "Western alphabet." And it gets worse yet again in cultures where the written page doesn't start at the top left.

One obvious way to get around this is make your GUI objects conditional to the text they have to hold, and to the display properties of the language in question, and never to paint screens or objects of a fixed size. But this seldom happens - designers hate that approach because it messes with the pretty.

Another subset of problem within this class is the periodic "untranslatable" phrase, word or value within the application. The word in question is always quite translatable. It just may be that the software application doesn't get the word from a list of resources designated for translation, but instead derives it with some business logic embedded deep in the application. I can tell you from experience that French customers are positively delighted when they see something like: Votre prochain balayage a lieu le Tuesday. They actually have laws against this kind of bug in France.

Anyway, this broad issue of how usable and comprehensible the software is once it's been translated gives us Category Two: Display and Usability Bugs.

The last group of issues are more complex, more insidious, and more dangerous. They involve the real "guts" of internationalization: Character sets and data structures. To illustrate my point, just look at this date:
  • 11/5/2008
Now, is that May 11, 2008, or November 5, 2008?

The correct answer is "Yes." If an application takes user input for dates, or displays time in the "local" convention, how it handles date stamps is very important.

Character sets are another class of issues that similarly result in vastly different and unexpected behavior, depending on how well the given piece of software handles them. Basically, each language system in popular use has its own character set encoding, or is covered by a "catch-all" standard. Not handling this well can result in on-screen garbage. Again referencing Wikipedia, here's a great essay on the phenomena called Mojibake:

Mojibake is often caused by forced display of writing systems or character encodings that are "foreign" to the user's computer system: if a computer does not have the software required to process a foreign language's characters, it will attempt to process them in its default language encoding, usually resulting in gibberish.

This works in both directions, and bad internationalization can cause gibberish to be displayed, or it can store gibberish, instead of, say, your password.

Another example of hits comes from static encoding of values that change in localized operating systems. For instance, many installer programs are "hard coded" to install software into the file system location specified by this string of characters:
  • C:/windows/program files/MyNewSoftware.

Well, again going to the French, on a French operating system, this "logical" directory would be represented by:
  • C:/Windows/Dossiers de Programme/MonNouveauLogiciel

There are ways to abstract your software away from this kind of information, so that it is either derived from the operating system or referenced using some locale-independent pointer. But this is often not done during the original design and "1.0" version of an application so it becomes an afterthought. Finding all instances where static strings are referenced, or where character set encoding is assumed to be ASCII or ANSI it tough, important work. These defects are bad, and can do horrible unpredictable things to software.

Important stuff this, and representative of Category Three: Data Structure Bugs.

That's my mental model, and my three categories of problems associated with changing the language on a piece of software. I take some liberties, I know, but this is useful for talking about a complex and wide ranging realm of software engineering.

I'll wrap with this: There's a new alpha-numeric abbreviation coming into vogue. It's globalization, in the context of "globalizing" your piece of software. It's abbreviated as g11n. The word is already too overburdened with meaning, so I really hope this one doesn't catch on.