Book Review - Get Your Frog Out of the Well

I just finished and enjoyed a short book by fellow New Englander Chuck Boyer, entitled:
Get Your Frog Out of the Well - Private lessons for the global economy.

The frog book, as the author privately refers to it,  is published by Wiley-India and is currently sold only on the Indian sub-continent. If you're reading my blog from the USA, you're going to have a hard time finding and buying this book. I apologize to my American audience for that, and I urge my Indian readers to head out to the book store right away.  Released mid-year, this book has been at or near the top of the non-fiction list in India ever since. And with good reason!

The framework for the book, as well as the source for the title, is a speech given in the 1890's by Swami Vivekananda, a Hindu teacher widely credited with the revival of Hinduism in India and beyond.  In the speech, he admonished his US audience to consider the world beyond their immediate line of sight -  and to not be "like a frog in a well."  (Chuck tells the story better in the book...)

The point of the parable, one I've frequently tried to get across in my blog posts about communication, is that the world is a big place, and that it's naive and foolish to consider only your own point of reference in any attempt to communicate with a global audience.  

This parable makes a great start to a book about communicating and working with Americans.  It's a fair summary to say that the book is written for professionals working in India's booming IT and software development industry.  These people are usually smart, well-educated technicians.  But they may not have the soft skills necessary to succeed when they are required to work with peers and managers in the USA.  I've experienced this problem first hand, and this book can help.  

Well researched and concisely written, this book offers good advice on communication style, keen insights into some broad general trends about Americans, and lots of stories and anecdotes that make the book approachable and keep it interesting.

So I think it's fair to presume that anyone interested in my blog will enjoy and learn from this book.  

I can imagine buying multiple copies of this book and giving it out to entire teams of engineers in India  It would make a great basis for a multi-part book-club meeting, to help the team talk through communication strategies and tricks to be more effective with their US peers or clients.  

If you're lucky enough to be in India any time soon, pick up a copy.  You'll enjoy it!

(as an aside, you can buy it here, but I didn't check to see what rediff will charge to ship a copy to the USA.) 


Chinese place names

So, is this Peking duck, Beijing duck, or Peiching duck?

This entry isn't strictly about outsourcing, but since much of what I talk about with my fellow outsourcing professionals is travel-related I thought this bit about place names in China was fair game. 

On my recent (first) business trip to China I was somewhat confused by the place names.  I had studied my guide books, but the names of cities  I saw on street signs and signs in the airports were all slightly different, depending on the context.  I presumed it was a post-colonial reversion to a more accurate phonetic interpretation of the place's traditional name, kind of like how Bombay became Mumbai.  Turns out I was close, but it's a bit more nuanced than that.

There are two competing conventions on how to render Mandarin Chinese into ASCII.  They are:
  • Pinyin: This is the official phonetic spelling guide for Chinese, as developed by the PRC in the 50's, and since adopted as "official" global standard for pronouncing and transcribing Mandarin.  Taiwan (The Republic of China) will adopt this standard in a few weeks, at which point we may presume many of their cities will become misspelled - overnite.  
  • The Wade-Giles System: This system predates Pinyin, and was developed by Thomas Francis Wade in the 1860's, then improved by Herbert Allen Giles in 1912.  Both these guys were British foreign service, so I was somewhat correct in my assumption that this spelling discrepancy was a hangover from the colonial era. 
There's a link here to a decent site that attempts to make sense of Chinese place names.  

In short Chengdu and Cheng-tu are the same city, as are Xian and Hsi An, as are Nanjing and Nanking.  In each case, the first name is the Pinyin spelling, and the second name is the Wade-Giles spelling.

Beijing, which is spelled "Peiching" in the Wade-Giles system, is still commonly referred to as Peking (and the airport code for the Beijing International Airport is still PEK).

And sadly, I did not have Peking duck on my trip.


China Outsourcing Summit - Days Three and Four

Days Three and Four

The final blog entry from my trip to the Gartner China Outsourcing Summit has hit a number of sequential delays.  First, I was struck with the news of the terrorist attacks in Mumbai.  Then, I was in a deep stupor having partaken of the traditional Thanksgiving feast last week.  Most recently, I've been frantically preparing, and last night delivering a one hour talk on outsourcing in China, entitled "China's Century, Hype or Hope?"  (more on that later...)

That out of the way, I thought I'd go through my notes and summarize days three and four of the summit.  These were spent in session with Gartner analysts, and in boardroom sessions with vendors.  I generally don't mind these 30 minute sessions, because they really are more "executive briefing" than sales pitch, and I learn a lot about the companies in question, as much based on their professionalism and presentation materials as based on their slide ware content.

The odd twist in this summit was that the presenters were a mix of companies and provincial government officials. I already explained the CCIIP - China Inc's PR and VC arm.  These presentations were by regional affiliates from the target cities supported by the 1000-100-10 Project, in Chengdu to tell people like me about the relative merits of Xian as compared to Shenzhen.

My quick summary of both the vendors and the officials is that there is very little to differentiate one company from another (they are all roughly the same age, roughly the same size, and they say roughly the same stuff about themselves), or one city from another (they are all large and new and populous and beautiful and harmonious and filled with the ephemeral goodness of harmonious socialist state).  That said, there are a few companies to watch, and there is a significant cost differential in China as you move away from the coastal cities.

Gartner highlighted the following companies as "top 10" by size.  I'm not going to list the sizes here, or for that matter the URLs to the companies, since you can find this info easily if you're interested, and the Gartner stats on headcount were already significantly out of date.  Here are the ten "largest" Chinese IT Outsourcing companies today:
  1. Neusoft
  2. DHC
  3. SinoCom
  4. Hisoft Technology
  5. Chinasoft
  6. Vance InfoTech
  7. Achievo
  8. Insigma
  9. iSoftstone
  10. Beyondsoft

My short list of "companies to watch" is:

  • DHC - These guys impressed me by talking about what they could do, instead of flashing up a bunch of Visio diagrams of network architecture and OSI stacks.  They understand how to talk to buyers, which means (I think) that they understand something about business.  I think they'll be successful, if they can continue to manage their service delivery.  They have also secured significant venture investment from their customers, which I take as a good sign.

  • Beyondsoft - These guys are big (tenth largest) and have staffed US-based service delivery with US-resident Chinese staff who understand how to do business with Americans, and just as importantly, how to get business done in China.  

  • Freeborders (11th in size, they are the first I've seen to develop significant American-Culture sales and marketing in the US.  They followed up with me within two business days from the end of the summit, and have already gotten me scheduled for a lunch meeting to continue relationship building.  These guys "get it" in a way that will win them new business in the months and years to come.

Now... about the cities...

As I said, they have all invested in IT Outsourcing infrastructure and capacity.  The big difference I see is that the inland cities, such as Chengdu, enjoy a 30% cost-of-living reduction over Beijing and Shanghai. If you're going to China to be cheaper, you may want to head inland past the big port cities, and find a partner in Chengdu, Xian, etc.

A bit about the economics...

China is cheap.   Not as cheap as Vietnam, but much more massive, and probably in possession of a more educated workforce.  It's really tough to get a straight answer about this from anyone, but as near as I can tell, an entry level developer will pull in an equivalent of $US 12,000 a year. That's compared to about $US 20,000 for the same talent in India, and about $65,000 in the good old US of A.  As you get into the senior talent pool for development, the percentage of US scale is even more favorable.  But (there's always a but) there is a significant differential in cost of leadership experience (as in India), and good verbal English language skills.  As already mentioned, the coastal cities are more expensive than the inland cities.  Adding to this advantage are the tax incentives that the 11th 5-year plan has put in place to encourage growth in the IT Outsourcing Industry.

All in, China can certainly deliver Cheaper, if you can manage your vendors or your captive to ensure either parity or improvement in quality and productivity.

I got out into Chengdu both evenings after the conference let out.  I found the city beautiful and safe by night, bustling but not in a New York kind of way... I didn't really have much sense of being in China though.  It was modern and cosmopolitan. The people were stylish, and "western" in dress.  The cars were European brands.  I felt, to be honest, more like I was in Vancouver on a Saturday evening.

I did get to eat some genuine (I was told) Sichuan food.  It was spicy, in a way I've never experienced in the USA.  The "Ma", or numbness from the Sichuan peppercorns, was just amazing.  And apparently growing up in the south is good global training for spicy food.  I was eating with Chinese and Taiwanese Americans, who were breaking out in sweat over the spice in the food.  I was just enjoying it.  So either I'm the Rambo of the Mala Chicken scene, or they were giving "the white guy" different food...  Either way, my local Chinese takeout joint will  never be the same.

Sichuan Tofu Pot - Very spicy...

The trip home was a slow-motion rerun of the trip there.  Lots of airplane terminals, departure lounges, a fog of Yan Jing beer, and, 31 hours later, a car ride home from Logan airport.  
3 days of travel for 4 days of being there.  I'm not sure I'd do it again, but it was a great trip.  I learned a ton, and made some business connections I suspect I'll nurture and grow in the coming years.  Thanks Gartner, and thanks CCIIP for putting this on!


Mumbai attack aftermath...

So, I'm not really equipped as a writer to comment on the human tragedy of last week's attacks in Mumbai. But someone pointed out to me a truth about this event, and indeed about all "security."

The truth is this: The risk of traveling in India is no different today than it was this time last week, before the attacks. If anything, this will cause changes that will make it safer to travel and live in India, both for Westerners and for Indians.

I agree, though the emotional impact of watching the Taj Hotel burning is tough to get over.

All that said and done, the CIA's latest travel advisory urges caution, but stops short of advising curtailment of travel.  This is quoted from the CIA's 11/28/08 advisory (that expires on 12/31/08).  

Americans throughout India should be vigilant about security at all times. The Embassy and Consulates are actively assessing the countrywide security environment.  Americans are advised to monitor local news reports, vary their routes and times in carrying out daily activities, and consider the level of security present when visiting public places, including religious sites, or hotels, restaurants, entertainment and recreation venues.  If unattended packages are spotted, American citizens should immediately exit the area and report the packages to authorities.

Good advice for troubled times...


Attacks in Mumbai

I had planned to finish my trip report and write up my impressions of a dozen or so companies I chatted with in Chengdu last week.  Until late last night, when my wife checked the news on-line and pointed out this to me.

The summary is that there were coordinated attacks in Mumbai yesterday, at several 5-star hotels, and other places through the city.  Apparently the attackers were targetting Americans and Brits.  

"The death toll had reached 101 by early Thursday afternoon, with nearly 300 injured. WB Tayady, head of St George’s hospital, said most fatalities had been caused by bullet wounds."

I am largely desensitized to reports of violence in the news.  But this...  tragic and bad and distirbing and sad all at once.  I feel for the victims, and I think this starts to change my opinion about the safety of traveling and working in India...  

A few years back, I elected not to send work to a company in Indonesia, because I didn't think I would feel safe there, and I didn't think I'd be able to ask my staff to travel there without worrying about their safety.  India, I thought, has a long history of tolerance, and of dealing with conflict peacefully..   Well, maybe not so much any more.  It's too early to draw conclusions, but this is a big deal.  Fingers crossed for the remaining hostages.  I hope they resolve this, and rain vengeance down on the perpetrators. 


China Outsourcing Summit - Day 3

Some of the Summit delegates on a tour of the Tianfu Software Park

If you're following along this week, you know I'm doing a one-week phase-shifted live-blogging about the China Outsourcing Summit I attended last week.

This summit was hosted in the city of Chengdu, in the Sichuan province.  You'll remember the Sichuan province from the 2008 Sichuan earthquake, that killed around 70,000 people and devastated the region.  In Chengdu, located about 20K from the epicenter of the quake, I saw no visible damage remaining.  But the city has been busy.  This summit was clearly a focal point for the rebuilding and recovery effort; and everyone I spoke to about the quake had a nearly palpable desire both to illustrate the resiliency of the Chinese nation and, more importantly, just to get back to normal. 

That aside, my first full day in China began with an introduction to the power of an autocratic socialist state.  As part of the introduction to my tour of the IT parks in the city, I was made aware of two significant state decisions that have directly and materially benefited Chengdu. The first was the announcement of a $150 Billion (900B RMB) infrastructure rebuilding campaign that will last the next three years.  The second was Chengdu's inclusion in China's 1000-100-10 Project.

1000-100-10 Project

Here's the summary:  (You won't find this on Wikipedia, and I hadn't heard about it until this trip...)  
  • The 1000-100-10 project is part of China's 11th 5-year plan.  You'll no doubt remember 5-year plans from your high school world history courses.  Think of them as comparable, in American-centric terms, to the campaign promises of presidential administrations.  In the current (11th) 5-year plan, China seeks what seems to be achievable growth over pretty much every economic sector and measurement you could imagine.  It's an ambitious plan, in a long series of ambitious plans.
  • The 1000-100-10 program is a small subset of this 5-year plan, focused on China's emerging IT Services Outsourcing industry.
  • The "1000" comes from their stated goal of establishing 1000 mid-to-large scale outsourcing companies in China.
  • The "100" comes from the goal of winning the outsourcing business of 100 "internationally famous" MNCs.
  • The "10" represents the 10 "base cities" they've selected, in which the government is funding development of IT parks and centers of innovation comparable to the largest office parks in the US.  Think "not as big  as Silicon Valley" but significantly bigger than "the Cisco Campus in Silicon Valley."
  • For reference, the cities are:  Dalian, Shanghai, Xi'an, Chengdu, Shenzhen, Beijing, Tianjin, Jinan, Wuhan, Nanjing, and Hangzhou.  There are 11 cities in this list, a discrepancy for which I have found no explanation other than "1000-100-11 doesn't work, does it?"  
  • Within each of these target cities, the ChinaSourcing Working Committee (which I will introduce by simply saying "it is exactly what it sounds like")  is steering educational institutions to tailor degree programs to the needs of the outsourcing industry.
  • The Working Committee also runs the PR and marketing campaigns for these cities, and they do an amazing job producing professional collateral to "sell" the cities.  
  • The Working Committee has also led the creation of incentive structures that make it very attractive for companies and individuals to relocate or set up shop in these target cities.  The list of amenities the government provides includes:  100% income tax refunds for qualifying workers, spousal work placement, short-term company subsidies for hiring new college grades, 15% company-tax rebates with further incentives for companies with higher headcount, 1% total subsidy on software exports, and a "welcome home" bonus of 200,000 RMB for non-resident Chinese who return to China to start a business.  It's an impressive incentive package, and a fascinating communistic take on Keynesian economics.
  • Lastly, the Working Committee is responsible for the development of office parks in these cities, complete with shared lab space (with computers and software), managed infrastructure, and amazingly cool modern buildings.
There are links to translated summaries of the 1000-100-10 Project here and here.

A member of the ChinaSourcing Working Committee, telling us about Phase II of the Tianfu Sofware Park

As the picture above suggests, I toured one of these newly developed software parks.  It was impressive. The architecture was stunning.  The offices we toured were spacious, interesting, and full of people who were apparently gainfully employed for the companies located there.  The tenants at Tianfu Software Park (the motto of which is "a Five-Star Technological Platform Accelerating Industrial Growth") include some big names:   Nokia, NEC, IBM, Symantec, and SAP, just to name the highlights...

The day concluded with a welcome reception wherein I was obliged to sit and listen to about three hours of speeches from an array of government officials, committee members from ChinaSourcing, and Gartner analysts.  The talks were all given with simulcast translation (we all got receivers with three channels - Mandarin, Japanese, and English).  It was comparable to what I imagine it's like to be in the UN, only with software people instead of diplomats.  Below are some quotes I jotted down from the speeches.  These were interesting to me because they reflect the tone and rhetoric of the party and government officials, which I would describe as dogmatically optimistic:
  • "Will China become the global leader in IT Outsourcing?  This is only a matter of time!"
  • "There will not be another earthquake in Sichuan for another 2000 to 4000 years."  (I was told this might have been a bad translation.)
  • "This plan reflects the importance to building an harmonious socialist society."
...not your typical fare for a IT outsourcing conference in the US anyway.  

From a tourist's perspective, Chengdu is a pretty city.  The infrastructure is amazingly well developed.  Construction is booming, and there is no view of the skyline that doesn't include one or two construction gantries.  The only complaint I had was that it was gray - gray sky, gray streets, and gray horizon.  One of my fellow travelers (who manages a team of engineers in a coastal city in China) said this grayness is an omnipresent state in all Chinese cities, due to the large-scale pollution.  Having been in LA recently, I know this isn't exclusively a Chinese problem, but still, it's a sad portent of things to come.  

Foggy morning, 18th-floor view looking out over Chengdu

The People's Money

While I was in China last week, all the (English language) local news was zoomed in on China's economic stimulus package.  I'll write more about what the Chinese government is doing to stimulate the IT sector of their economy later today, but a few things were interesting to me, from a macro-economic perspective:
  • China apparently seeks to achieve something like balanced trade with the US.  According to my hosts this is more a matter of treaty than of policy.  Plus, the Chinese government has a lot of money sitting on the sidelines, so they actually need to spend.  Again according to my host, and independently verified with a bit of research and my own observations, one of the only things the Chinese government (and state supported industry) is able to buy in America is big civilian airplanes.  So, there are a lot of Boeing jets on runways in China.
  • Their internal stimulus package announced a couple of weeks ago was billed as a placating measure in their local press reports...  Apparently the People are not so happy with "slow" growth, even when that "slow" growth would look healthy by our own economic standards.
  • That's because of habituation.  The average rate of economic growth in China over the last 20 years has been over 10%, making it the fastest growing major economy in the world.
  • ... and on that front, this article from Financial Times is an interesting projection of what the recent downturn is likely to do to China:
The World Bank on Tuesday cut its growth forecast for China next year to 7.5 per cent, the slowest rate of expansion since 1990, and said the impact of the global financial crisis was likely to “intensify”.

The interesting thing about this is that China's plans to forestall the slowdown involve turning attention to domestic consumption, away from exports.  That means China, the world's workshop, is about to start shopping itself...


China Outsourcing - Days One and Two

6829 miles to destination.  That picture, taken off the in-flight TV on the tarmac at Idlewild, pretty much sums up Day One of my trip to this summit.

Six.  Thousand.  Eight.  Hundred.  Twenty.  Nine.  (Expletive deleted).  Miles.

And that's just one of the three legs of my trip.  It's the long flight, the one that goes over the North pole into Asia, but still only one of three.  This is an inescapable fact of China Inc., and of choosing China as your sourcing destination.  It is, quite literally, on the other side of the planet.  In a way that makes India seem close by comparison.
This long flight, coupled with the fact that I flew West across the international date line means that Day Two is also summed up with the same 4-digit number.  6829 miles to destination.

This might be a good time to bring up jet lag, but of all that has been written on the topic, there seem to be no truths, no stratagems, no approaches that actually do anything to help me.  So we won't speak of it, except to say that every trip I've ever done more than 6 hours off my home time zone has passed in a haze of sleep deprivation and vertigo.  Flying to China of necessity puts Americans, and to a lesser extent Europeans, well off their circadian rhythms. 

Instead, I'll dwell on the brutal and simple duration of this travel.  It seldom gets scrutinized as one of the hidden costs of outsourcing, but if you plan on setting up shop in China, you can also plan on spending about three to four percent of your effective work year on airplanes.  Two days going, and one day coming back, for each trip.  It's not an argument against sourcing in China, or against outsourcing in general, but it is something that should get real scrutiny when planning the financials of an outsourcing deal.

I was lucky enough in this trip to fly business-class, on China Air.  CA's business-class seats are not the best in the world.  The particular 747 that flies the Beijing / JFK route is old and tired, and the seats are not quite up to the "modern" standard set by BA and Virgin Atlantic.  But even old business-class seats that don't let you lay down flat are better than coach seats.

I've written about this before, a few years ago, but this might be a good time to reiterate my opinions about business-class travel.

That flight leg from JFK to Beijing took about 14 hours in the air. Make that 15 hours if you count all the runway time.  Try to sit in a coach seat for 15 hours.  I just dare you.  If you're over 30, it's a guaranteed trip to the chiropractor.  There's a reason "Business Traveler" magazine exists, and why it devotes most of its editorial content to reports about which airline has the best lie-flat seats. At 15 hours, this is a flight that could kill you.  The slow painful way, via deep vein thrombosis.  

Business-class, in addition to the free drinks, allows you to get up and move around, to shift seating postures, and to really try to rest.  It would be a pretty tough travel policy that didn't allow upgrades to business on legs over about 8 hours.  But it isn't cheap.  The summit paid for my travel (the fare for which was no doubt heavily subsidized by Air China, since more outsourcing in China will mean more people on that JFK-PEK flight...), but when I priced out a similar itinerary for reference just now, it comes to around $10,000 US, any way you fly it. Do that three times a year and you've suddenly added a significant amount of travel budget to your sourcing program.  

This is obvious, but a lot of people forget to budget for this when they start their outsourcing search.  To make outsourcing work, you have to travel, and the travel is both expensive and time consuming.

On that note, I'll briefly describe the play-by-play of my trip.  

I started my day at 07:30, well, 05:30 to be honest, when the alarm went off.  

I was nervous about this trip in a way I haven't been in a long time.  I've been to Asia a dozen times by now, but never China.  I talked with my wife about what was making me nervous.  It came down to, well, China.  People's Republic of.  

Suffice to say their reputation precedes them.  I already decided not to try to post any blog entries while I was there.  I already decided not to write a script to do NSLookups of all the domain names in the world to see what hostnames resolved as in China.  I just didn't want to invite any scrutiny that could result in my laptop being confiscated or searched, or me being detained for questioning. In planning for this trip, I was reminded of the apocryphal Chinese curse: May you live in interesting times, and come to the attention of those in authority. I guess my guiding principle on this trip was that I didn't wish to come to the attention of those in authority.

The first leg of travel was uneventful, and the only issue with the transfer to the last leg was an apparent incompatibility in the ticketing mechanics between China Air's JFK desk, and their Beijing hub.  But after 25 hours in airplanes and airports, I was in the air over mainland China, on my way to Chengdu.    Oh, and in what I suspect is a common mistake, my ticket was entered under the name Mr. Hickman Thomas.  In China, the family name comes first, the given name last.  So, I think it's a common mistake for Chinese travel agents to make.  The only airport that had a problem with this was Boston's Logan.

The staff of China Air, and through all the airports I traveled have nearly perfect English language skills.  My car ride from the Chengdu airport to the Shangri-la hotel was an uneventful 20 minutes in a VW Passat.  The only impression I had of China that first night in-country was that the cars weren't interesting (mostly European and American brands), and that I'd never be able to drive there myself unless I learned some Mandarin (the signs have only cursory English language translations).  Aside from that, Chengdu, with its wide streets and multi-lane highways, could be any European capital.  It's that big, it's that clean, it's that nice.

Bentley dealership, Jinjiang Dong Road, Chengdu

My day ended at about midnight local time with a seamless check-in at the Shangri-la, in a nice non-smoking room and a comfortable bed, in which I failed entirely to sleep for the next 7 hours.

27.5 arduous but uneventful hours door to door.  And I am, for the first but probably not the last time, in China.

All this week -- semi-live blogging !

I am just returned from a one week trip to Chengdu China, where I attended the Gartner China Outsourcing Summit, 2008 Edition.

Because of some (possibly unfounded) fears I have about the Chinese government's information policing policies, I decided to wait until I'm safely back in my homeland before I posted these blog entries.  

What follows over the next few days is my account, day by day, of my trip to Chengdu, what I saw there, and what I learned.

Read and enjoy.

Gartner China Outsourcing Summit - 2008 

Phase-shifted LiveBlogging


Getting it in the cross-hairs

I had the opportunity this week to lead a couple of dozen managers through a target-setting exercise to define their expectations for a large, diverse outsourced offshore team.

I designed the exercise with particular attention around the offshore part of this particular engagement, but as I have said many times, managing offshore outsourced teams requires basic management skills, and the exercise took a back to the basics approach.

In my exercise, we called the overall process goals and objectives or GAOs. The name doesn't really matter, and I have heard and/or done this exercise as key performance indicators (KPIs), management by objective (MBOs), key growth areas, or simply deliverables.

The name does not matter, what matters is the communication. What matters is that management clearly articulates expectations, and treats this process with urgency.

Here is the summary of the voice-over from my exercise:

The exercise is about establishing and communicating goals and objectives for your offshore staff. 

Remember, these folks are your staff. You are responsible for their work, and they are responsible for helping make you successful. So some of these GAOs will cascade directly from your GAOs as managers and business leaders.

However, because of some of the unique aspects of offshore contract teams, some of the GAOs will be specific behavioral expectations, and some will attempt to fix bugs in the partnership.
The important thing here is to document your expectations, then to communicate those expectations to all stake holders (your offshore staff, as well as your retained team).

This has the short term benefit of letting people know what they're accountable for, and giving them a chance to be successful.  There is a long term benefit of preparing yourself and your organization to measure cost effectiveness of your service delivery, and to begin managing to a service level.  

How do you start?  I've watched dozens of managers try to work through establishing and documenting GAOs, and it’s always hard.  I've developed a few simple catalyzing questions that seem to get people thinking...

  • What do you need your (offshore) staff to do over the next 90 days, in order to meet your business objectives? (This becomes the basis for operational GAOs and targets.)
  • What metrics do you already use to measure performance of your offshore staff? If you don’t have anything in place, what could you easily implement via pick-and-axe work? (This will define how to measure performance against these GAOs.)
  • What if any issues or disappointments have you had over the last couple of quarters? (These are the bugs you need to patch through behavioral GAOs.)
After getting managers to think about this, I remind them what a bad GAO looks like. 

Simply put, bad GAOs are non-measurable, subjective, vague or implicit, or unachievable.
Examples of bad GAOs, with some reasoning about what makes it bad, follow:

  • Add value to the team. This is bad because you cannot directly measure value, and someone may think they are adding value when in fact they are negative value-add.
  • Deliver Widget X with high quality. "High quality" is very subjective.  
  • Deliver Widget X with zero defects. "Zero Defects" is impossible to achieve, and this GAO will set the team up for failure.
  • Deliver Function Y on time. "On time" may be clear to the author of this GAO, but it does not communicate to the staff what exactly is expected.
Following that, I presented some good GAOs. All of these are objective, clear, concise, self-contained, and explicit.  Where possible or practical, they should be jointly developed.  And most importantly, they should be clearly communicated to the staff responsible for execution. It’s really as simple as this…  

Some good GAOs might look more like this:
  • Obtain proficiency in development processes through completion of on boarding training, followed by proficiency quiz.
  • Deliver Widget X in the November release, with no more than 2 S1 defects and 4 S2 defects "leaked" to the field within the first 90 days of production use.
  • Deliver all specified behavior in Function Y, by 11/31/2008.  Pass full code inspection and acceptance testing with less than 5% rework.
The difference in each of these good GAOs is that they are precise, they define the target, they define the time line where applicable, and they define the means by which success will be measured. 

The last bit of my talk was about behavioral GAOs. This is a method I've used successfully to get around sensitive cultural or enterprise-to-enterprise relationship issues. A couple of examples follow:

Scenario 1:  An architect-level resource from a service provider was involved at a very deep 
level in a client project. When the architect perceived a problem with the project (that ultimately resulted in a schedule slip), they escalated first to their own (service provider) chain of command. The service delivery director received the escalation, discussed it with the staff involved, and then escalated to the client-side senior leadership.  
Problem: This escalation chain was troublesome to the client, because it created a secondary, unintentional chain of command within the project. They wanted the senior service provider resource to work directly with the product team, rather4 than through a “shadow” management team.
GAO we used to fix it: We wrote a GAO something to the effect of:  Senior architect resources should act and behave as if they were “badged employees” with respect 

Scenario 2:  In a large ITO portfolio with multiple client-side managers, there was some confusion and surprise around staffing coverage in the Indian delivery center, on an Indian national holiday. A reminder that staff would be unavailable went out the day before the holiday.
Problem: This caught many of the client-side managers by surprise, and they had to do significant schedule-shuffling to ensure coverage while the India-based staff was on holiday.
GAO we used to fix it: The service provider management team was asked to send reminders for national holidays and planned personal vacation to all affected client-side manager 2 weeks, 1 week, 2 days and 1 day in advance of the event, to ensure that client-side managers have more than ample advance notice.

These last two scenarios illustrate the organizational or behavioral GAO I mentioned at the start of the post. This method can be used to fix real or perceived bugs in how outsourcing partners relate to one another.

Over the next few weeks, I’ll be getting draft GAOs from about two dozen client-side managers, so I should have some interesting source material about how managers across a wide spectrum of experience approach the problem.


Finally, someone as panoid and cynical about security as I am...

I just stumbled on this excellent list of "security maxims" from the Nuke E. division of the Argonne National Laboratory.  They describe it as "cynical and tongue in cheek."  In my opinion, this just makes it good reading, not less valuable or true.  Read and enjoy.  Here are some excerpts:

Ignorance is Bliss Maxim: The confidence that people have in security is inversely proportional to how much they know about it.

Huh Maxim: When a (non-security) senior manager, bureaucrat, or government official talks publicly about security, he or she will usually say something stupid, unrealistic, inaccurate, and/or na├»ve.

Really, just great, well written, kind of funny truths.  Check it out.


We’re all experts…

I had to take a commercial flight yesterday morning. As is usually the case, I was amused by the latest changes in the TSA’s security theater.

For those readers who have not traveled in the US recently, I will remind you that prior to entering the terminal travelers have to go through security screening. To be allowed into the terminal, you have to:

  • present photo ID and boarding pass
  • resent your carry-on luggage to be x-rayed
  •  remove your shoes and any coat you may be wearing
  • place them on a flat bin to be x-rayed
  • take your computer out so it can be x-rayed by itself
  • remove any liquids such as shampoo or toothpaste from your luggage
  •  ensure said liquids are in containers no larger than 3 ounces by volume
  •  ensure that the containers of liquid are in a one quart clear plastic zip-lock bag
  • walk through the metal detector while carrying your boarding pass

As Security Theater goes, it’s actually not that bad. I've had more intrusive security checks in Asia, and I've had more thorough scanning for possible weapons or explosives in both Brussels and Paris. But it is a lot to ask people to get right.

That list of procedures places a lot of expectation on the traveler. And people mostly get it wrong and gum up the works.  If you remember any of my recent posts about checklists, this is a set of complex high-expectation tasks.

The TSA clearly had the bright idea of segregating frequent travelers from neophytes, so the “frequent traveler” line would work like the express lane in grocery stores… you know, 14 items or fewer, cash only. 

But, the way it was implemented was laughable and made matters worse. And it played into a facet of human nature that frequently hurts those of us involved in managing offshore partnerships or teams. The implementation was this:

At one end of the terminal, there was a sign stating that there were three lines prior to the screening. One was for novice travelers.  One was for experienced travelers. One was for expert travelers.  You had to work your way through a maze of rope barriers for each line, so you couldn't really tell which line was shorter. So everyone picked according to how well they thought they knew the TSA regulations.

Once I got deep into the maze, I could tell that I picked badly.

There were about 150 people in the “expert” line. There were about 50 people in the line for “experienced” travelers. There were two families, seven people total, skipping to the front of the “novice” line and going through their own private. If you were smart, you would have selected that line. But no one did.

Almost everyone asserted that they were experts.  And as a result, all the self-proclaimed experts had to stand in line for 45 minutes waiting to get to the screening tables.

This efficiency effort failed because of a fascinating facet of human nature that inflates our assessment of our own skills. 

I have run “self-assessment” programs with engineering teams and people usually treat it as an affirmation of their aspirations rather than a true and honest assessment of their capabilities. And people will very rarely publicly admit that they are novices at anything.

So, the TSA should clearly try to find a better way to select for their express lane. Maybe they could select by number of bags and get the desired effect of sorting out people who are likely to forget some of the requirements I noted above.

But more interestingly, the object lesson in this is that you should find a better method than self-assessment when analyzing your team’s expertise. Because clearly, we’re all experts.


An interesting idea...

So, I just today learned about this company - 6th Sense Analytics - out of RTP.  They're building what seems to be low-footprint inter-IDE metrics gathering widgets that they deliver as a software enabled service to their clients.  It's one of those ideas that is immediately obvious when you hear about it.  Enough so to make me smack my forehead and say "why didn't I think of that..."

I am trying to find out more about them, and will post more when I do, but their web site might be a few minutes of browsing for anyone interested in metrics and performance analytics in software development, whether it's done onshore or offshore.


The last bit of my BC talk

As frequent readers will remember, I've been posting about my recent talk at Boston College. Previous excerpts are here and here.

This is the last such excerpt.

After talking to the students about a framework to understand global outsourcing and then speaking about the way a leader should look at the job of managing a global team, I tried to impart some lessons-learned. Since much of this content has been covered previously in this blog (look for the "best practices" tag), I'll be brief. I said, with supporting anecdotes in most cases, the following:
  • Managers can delegate authority, but not responsibility. This is often lost on neo-mangers, who will point to the outsourced team and blame them for problems without understanding that they themselves are responsible for the actions of the vendor team.
  • People are not capacity, even though it's seductive to talk and write about "labor pools." Humanize your team. Try to know them by name. Put them on your organizational chart as people, not as "capacity blocks."
  • Communication is made slightly tougher by distance, and tougher still by cultural and linguistic differences. Don't let this overcome you, but adapt: Remove idiom from speech, use good communication tools and technologies, and always seek written confirmation of verbal communication.
  • Use checklists for high expectation tasks. Make tacit knowledge explicit where ever possible.
  • Building a global team, whether insourced or outsourced, takes time. Don't give up before you start to see return on the investment. Avoid "shiny object syndrome."
  • If you want to be "faster, cheaper and better" be ready to answer the question "...than what?" Measure your operations, and use those measurements to inform your outsourcing governance.
  • People fear outsourcing. They fear difference. They fear losing their jobs. They fear competition. Understand that fear, but don't be mastered by it.
Lastly, I presented my belief that outsourcing is its own extant body of knowledge. I used this graphic, directly from my current sales pitch for my consulting business, to illustrate the fact that there is a lot of complicated knowledge hiding behind the simple decision to outsource something...
Judging by the Q&A throughout the presentation, and the people who grabbed me at the end to talk one-on-one, it was a successful presentation. Hopefully, these blog posts captured some of that.


More from my recent talk at BC

This is the second in a series of blog entries summarizing my recent guest lecture at Boston College's Carroll School of Management. The first excerpt is here.

After laying some foundation about the variety and difficulty of global technology teams, I spoke about the importance of selecting the right people to manage a global effort.

Without naming names, I referenced the dozens of great "local" managers I've known through my career who failed utterly in their efforts to manage globally distributed teams.

I spoke particularly about one manager who worked for me - a star in my organization, highly effective, liked and respected by his staff - who in less than a year destroyed a highly functional global team, taking productivity to near zero and creating a massive attrition problem for the person who ultimately replaced him.

The issue wasn't that manager's commitment to the global team. It was that his skills as a manager and a leader no longer applied in the new global context. He didn't adapt or develop new skills to face the challenges of managing a global team.

Particularly, he was no longer able to do "management by walking around," he no longer had the benefit of a team that was capable of sharing tacit knowledge, and he no longer had instant rapport and cultural affinity with all members of his team. In short, he was not a great manager once the rules of the game changed.

I wrapped up the object lesson by stating that it's easy to be a great manager when you've got a great team, all co-located, all knowing exactly what their job is. Adding challenges to this mix is something great managers will overcome. But average or bad managers will not be able to overcome this. In short, globalization may be the straw that breaks the camels back. But it's still a straw.

Being the info-graphic addict that I am, I had a pie chart to make my point.

Most people who begin managing global teams see their world like the graph above. They believe that 80% of the problem is the "offshore team" component. In a globalized world, this view is just wrongheaded, and it will doom this manager to failure.

A better view of the world comes from analyzing successful managers who build or manage great global teams. They aren't more culturally attenuated. They don't have better tools. They don't have magic pixie dust that makes cross-cultural communication easier. They just learn and adapt their management style to new situations. That is, great managers can metabolize the new challenges of a global context because they are great managers. They will inevitable see the world like this:

In this view, the "offshore team" component is maybe 20% of the problem space. I've spoken with knowledgeable experienced technology executives who will argue that it's even less than 20%. Either way, it's not the big piece of the pie chart. The big piece is "I manage." What does "I manage" mean? It means taking responsibility, while delegating authority. It means building a team. It means telling people what you expect of them, and holding them accountable to achieve it.

I'll talk more about this in my next excerpt from this talk.

More later...


Excerpts from my recent talk at Boston College

Several weeks ago I had the opportunity to present a guest lecture to a grad-level symposium on outsourcing theory at the Carroll School of Management at Boston College.

I attended Boston College for several years in the '90s. At the time I thought I wanted to be a philosopher when I grew up. Turns out love of wisdom is not a growth industry.

I actually started my career in high tech at BC, working in their IT shop to fund my graduate studies in the Philosophy of Science. So I always enjoy going back to the campus.

And as an added bonus, the course was taught by a man I like and respect - Mohan Subramaniam, D.B.A.

Professor Subramaniam is the author of a significant amount of new theory and scholarship in the space of global innovation, and really knows his stuff. I was delighted to have the opportunity to talk with him and his students.

The attendees were a mix of professionals and MBA candidates. Their experience level ranged broadly. I tried to keep my comments generic enough to apply to all levels. What follows is a transcription of the salient bits of my presentation:

Managing Global Teams – a Practitioner’s Perspective

I began my talk with a description of the high-level thought processes that drive most organizations to begin outsourcing some portion of their operations. In my experience, this starts with a tacit desire to be faster, cheaper, or better.

All business-drivers that ultimately lead companies to outsource fit into one of these three buckets.

I defy anyone to find a driver that is separate from the desire to be faster, cheaper, or better. The class took me to task on this, and presented some drivers they thought fell outside of my purposefully simplified model:
  • More flexibility in ramping up or eliminating staff - This may be faster, it may be better, or it may be both, but it certainly fits into the model. Faster ramp-up, better ability to align resources to business realities.
  • Access to a large or talented labor pool - This is a form of better. Access to better people than you might otherwise be able to attract and retain.
  • Ability to slough off non-core work and focus on the core -- This too, I argued, is very simply a form of better. Ability to focus on the core is the ability to be better at what is important to your company.

I then presented this flow chart, that sums up the decision gates most companies go through:

If you’re good at this stuff you’ll enjoy good results. You'll be faster, cheaper, better or some combination of the three. Hooray! Good for you.

But if you’re not good at this stuff, you will fail. Like this. Or this. Or this.

In order to understand "this stuff" you first need a framework to talk about the various flavors of outsourcing. I presented my framework.

All sourcing models, I contend, boil down to two questions: Us or Them? Here or There?

I presented the attendees with my UTHT matrix. This matrix, taken from the opening chapters of the book I’m working on, defines a simple 2X2 matrix (I do love a simple 2 X 2 matrix!) and lays out a way to describe all outsourcing team models into 4 quadrants, and 5 team variants.

The team variants I described are as follows:
  1. Pure Local Insourcing
  2. Global Insourcing
  3. Local Hybrid Teams
  4. Global Hybrid Teams
  5. Pure Global Outsourcing
I talked about how each of these 5 team types is subject to a 4-fold problem. Most "traditional" technology teams deal with at most 2 of these facets. In three of these five outsourcing models, you double the complexity of the working dynamic, and face all these problem facets:

Outsourcing is difficult. It adds complexity. In traditional teams you have to deal with the problem space and the team dynamics of your local team. That’s an easy set of problems. You know technology or you wouldn't have gotten the chance to lead a technology team. You know your team; and you probably manage them by walking around. Throw in the complexity of vendor and client relationships and an extra team with potentially conflicting culture and goals - and you've got a real mess.

I use this same slide in my vendor training to describe the fact that outsourced service providers have among the toughest jobs on the planet because they have to be savvy and proficient across all four of these facets. This part of the talk really resonated with the more experienced attendees. I think the truth of this statement may be lost on younger MBA candidates who haven't had the difficulty of managing across multiple facets of a problem space...

This was all to lay the background, and to give the attendees the understanding that the simple, obvious decisions (sic) they’re making and suggesting around their theoretical work and case studies in outsourcing create a whole new level of complexity once implemented.

That’s probably enough for this post.

In my next extract from this talk, I’ll go through the “lessons learned” portion of my talk.


Book Review - Dealing with Darwin

This is another in my very erratic series of book reviews, and is a departure for me.

Normally, I don't like or enjoy business books. I prefer non-fiction with good business-related object lessons, at least for the book reviews I write for this blog. But I just read Geoffrey Moore's new book called "Dealing with Darwin." I found it enjoyable, but also useful and directly related to global outsourcing strategy. Hence the review.

Dealing with Darwin provides a lucid explanation of the Core versus Context debate, and how to use it to inform business decisions.

Here's Moore's explanation in a nutshell:

Core work produces sustainable competitive advantage. Context is everything else.

An important difference in Moore’s explanation, and one that is lost on people trying to intuit their way through the core / context analysis, is that context isn't synonymous with unimportant.

Moore defines a 2 X 2 matrix, as follows:

  • Core versus Context on one axis
  • Mission-Critical vs. Non-Mission-Critical on the other

This gives you the following handy magic-quadrant that you can use to "rank" what your business or organization does. (I wrote last week about using this approach to inform strategy. Read about it here and here.)

The four quadrants, to summarize with some license applied, break down like this:

  • Quadrant 1 -- This is where you innovate and invent. You create new differentiated offerings here.
  • Quadrant 2 -- This is where you deploy your new differentiated offerings.
  • Quadrant 3 -- This is where you operate. I think it's fair to assume that most IT and an awful lot of post-1.0 software development work happens here.
  • Quadrant 4 -- This is work you offload, or cease doing all together.

The last interesting thing Moore says, directly relevant to the question of what and how to outsource, is that you can rotate people from quadrant-1 to quadrant-2, and from quadrant-4 to quadrant-3. This is, to paraphrase, contrary to the harsh Darwinian position that you lay off people as their work becomes non-mission-critical, and hire new people with new skills to innovate. He correctly points out that this erodes morale and destroys the positive aspects of corporate culture.

Moore's a good, accessible writer, and this is an important book for anyone attempting to chart strategy around business investment or sourcing.

Buy it and read it!


More on core versus context

Earlier this week I ran an exercise to walk an executive team through a core versus context ranking. The exercised was designed to generate animated discussion towards a clearly articulated multisourcing strategy.

The exercise was moderately successful, but a few things popped out:

For starters I'll remind the reader (and myself) of the 4 quadrants I used for this exercise. These are as described in Geoffrey Moore's Darwin book.

The exercise I suggested was to create a catalog and inventory of services and then map them into these quadrants. I prepared a few examples and asked for dialog around what quadrant was most appropriate for each example service.

Service Descriptions are difficult to write

Not surprisingly, the first point of debate was around the definition of a service. I had carelessly described an example service as "Active Directory Administration." That caused a lot of confusion, because depending on personal perspective the service was interpreted differently. If you read that service statement as "user provisioning, access and control" it's mission-critical. If you read it as "system administration of the AD servers" it is arguably non-mission-critical. The important lesson here is that service descriptions need to be tightly written, and need to focus on the business value derived from a service, not the tasks required to deliver a service.

An obviously bad service description might be:
  • Active Directory administration
A better service description might be:
  • The organization provides a service (currently but not necessarily run through Microsoft Active Directory) to manage user credentials and single-sign-on logins for the global IT infrastructure. In provision of this service, new users must be added within 1 business day, password resets must occur in real time during normal business hours, and user accounts must be terminated with a one-hour SLA, 24X7. This service includes and subsumes all necessary procurement, topology design, software installation and maintenance, system installation and maintenance, and day to day operation necessary to provide this service to the business.
With that service description, there would be less debate about what was included in the notion of the service, though even with "24X7 " statements in the service description you might bump into the second lesson of this exercise:

"Mission Critical" is not intuitive or self-evident

As I led the discussion about where various IT and development services fell into these quadrants, the core / non-core part if the model seemed to be self-evident to everyone involved. Moore's description - which I paraphrased as "providing sustainable competitive advantage" - is clearly a good, easily internalized yardstick.

However there was much debate around what is and what isn't "mission-critical." Most of what I've read defines mission-critical with synonyms that mean "mission-critical." It's better to define it in terms of impacts to the business, and the pain threshold a business is willing to endure.

An application or service is mission-critical if its failure, cessation, or temporary absence results in unbearable negative impacts, such as:

* Financial penalties or significant loss of revenue
* Lapse of regulatory compliance.
* Injury or loss of life
* Severe degradation of operational efficiency
* Severe adverse public opinion or publicity

The frustrating thing for anyone attempting to use this methodology to inform their sourcing strategy is that it's an "onion peeling exercise." These business impacts listed above are only examples. These items align to the corporate identity and strategy, and as such, what is mission-critical for one company will not be so for another.

So the lesson is to first develop a rough guideline of the pain threshold you're willing to tolerate, and use that guideline to inform your M-C / N-M-C analysis. Your mileage may vary on what is / isn't mission critical, but I'd use the bullets above, and define "temporary absence" as one business week. That will help make it easier to slot items into mission-critical or non-mission-critical.

Missing some important data

The last lesson from this strategy-building exercise is that the quadrant analysis may help you decide what reasonable outsourcing or multisourcing targets you have in your portfolio, but it doesn't necessarily help you prioritize.

It would be tempting to say that you'd go counter-clockwise from quadrant 4, first attacking N-M-C context, then N-M-C core, outsourcing and freeing resources accordingly.

However, it might be more appropriate to look at areas where you can get good bang for the buck, as well as areas where you don't have core competencies or skills to match your aspirations. Hence, I think a couple of modifications are necessary to make this model work well.

First, I'd suggest "surface area" modification to the service inventory. This data may be hard for organizations to track down, but when you inventory your services, also note the estimated dollar amount (fully burdened) that providing the service costs your organization. Then, represent the service as a "dot" where the size of the dot is proportional to the amount spent on the service. Spend $25M on managed network services, you have a big circle. Spend $50,000 a year on managed network services, and it gets a small circle.

Then, you can quickly visualize the "low hanging fruit" in your service portfolio. It may not be prudent to begin an effort to outsource non-mission-critical context if you can only save a very small amount of money or free up a very small amount of time through the effort.

Lastly, this model doesn't represent an organization's core competencies, just their core services. If you aren't very good at providing Enterprise Messaging, then maybe you should consider augmenting your skills through outsourcing as a high priority. A simple modification, encoding the service with your organization's capabilities, will produce another visual representation that will allow you to quickly scan for high priority areas. You can do this by a "gut feel" ranking of core competency, as good (green), moderate (yellow) or bad (red). Obviously, large dollar, low competency areas should be addressed with priority, regardless of what quadrant they fall into.

This model would produce a visual representation like this:

In this model, it's probably more important to have an approach to solving the lack of skills and competency in Service 1 than it is to free up the resources delivering Service 4.

So in this case your outsourcing strategy needs a statement of how you would augment skill in new service development, either through outsourcing to a qualified firm or outsourcing through M&A activity with some attractive start up in the space.

At any rate, the model generated excellent debate. This can be used to build consensus, and also to inform a strategy. With the modifications I suggest above it can help prioritize what areas of your organization you view as viable targets for outsourcing, staff / skill augmentation, etc.


Assessing what to outsource

I've read pretty much every major book on outsourcing. They all devote considerable page-count to the determination of outsourcing strategy. But they mostly miss the mark. There are dozens of models, developed and no doubt used to good effect by dozens of authors. But mostly in my opinion and in my experience, determining what you can safely and productively outsource boils down to advanced common sense.

But that's a tough concept to teach, or to relate to other people.

That's why I was somewhat excited when I picked up and read Geoffrey Moore's new book called "Dealing with Darwin." The book isn't really about picking what you outsource and what you don't. It is about picking what is core to your business, and what is contextual, and then allocating resources accordingly. But the lessons are directly applicable to the question of what to outsource.

This core / context matrix gets referenced a lot in business. But few people I've heard use this model have a crisp definition of what is or isn't core. Moore actually does a decent job of defining core and context. In a nutshell (to save you the 8 or 9 hours it takes to read the book), core work produces lasting differentiation that allows you to retain customers and hence charge more for what ever it is you do... Context is everything else.

Put differently, core is that which your customers believe they can and should buy only from you, context is all the stuff you do to manage to deliver it.

Moore defines a 2 X 2 matrix, as follows:
  • Mission-Critical vs. Non-Mission-Critical on one axis
  • Core versus Context on the other
This gives you the following handy magic-quadrant, that you can use to "rank" what your business or organization does.

The four quadrants, to summarize with some license applied, break down like this:

  • Quadrant 1 -- This is where you innovate and invent. You create new differentiated offerings here.
  • Quadrant 2 -- This is where you deploy your new differentiated offerings.
  • Quadrant 3 -- This is where you operate. I think it's fair to assume that most IT work happens here.
  • Quadrant 4 -- This is work you offload, or cease doing all together.
The 4-quadrant approach lends itself to an exercise you can use as a preamble to creating an outsourcing strategy. The way I'd start this exercise it with a service inventory. This is a little different than what Moore does. He's talking about markets and geographies and big-picture business decisions. But if you're an IT leader, you're not worrying about whether to try to crack into the AsiaPac DSL market. You are, however, worrying about how you're going to provide messaging services to your business.

It's important for the sake of this exercise to separate services (stuff that the engineering or IT organization provides to the business) from a task inventory, for example, this might be a quick task inventory for "Exchange messaging services":
  • Active Directory User provisioning.
  • Exchange server patch management and server upgrades.
  • Storage administration.
  • Incident response and troubleshooting.
  • Spam filter administration.
  • MX record administration.
  • User de-provisioning.
These tasks, while important, don't really matter for the sake of this argument. The service - "messaging" - is what counts. As a service, messaging might best be described as:
  • Providing individual users with the ability to send, receive and store RFC 822 electronic messages from within the company, as well as from individuals at other organizations.
What quadrant does this fall into?

Unless your company builds mail servers and sells them, or offers hosted e-mail to your customers, I'd suggest that your messaging service is contextual. Your customers don't buy messaging from you. That said, it depends on your business whether this is mission-critical or not. Either way, this is a Quadrant 3 or Quadrant 4 service. It's contextual. In my book, that means it is a candidate for some kind of outsourcing. Maybe if it's mission critical, you manage the service, but seek offshore staff augmentation. Maybe if it's non-mission-critical, you outsource it entirely, and just buy it from some company that provides e-mail service to other enterprises.

If you go through everything in your service portfolio, and take the lessons Moore develops for markets and apply them to the much smaller fractal pattern of IT services or product engineering, you can quickly develop a landscape out of what once might have seemed to be a melange of unrelated tasks and services. And you can see, in an act of advanced common sense, what you should do about all these services you have to provide to your business.
  • Those things that are core, and non-mission critical may need more investment.
  • Those things that are context may need offloading, cessation, or augmentation.
To follow Moore's guidance you should try to offload resources (people or money) from contextual work and put it on core work. That's what will differentiate you in the eyes of your customers, and that seems like a pretty good starting point in determining what you can and can't outsource.

I'm leading a facilitated discussion on this topic this week. So more on this later, after I try to walk some people through this line of reasoning.