21.7.08

Best Practice - Contract must-haves


I've been reading some pretty dry government documents put out by the FFIEC, about audit practices for financial institutions. They list what I hold to be an obvious but good framework of "must haves" for outsourcing contracts (or any contracts, really). I've been intending to write down my own thoughts on contract framework best practices ever since I went through the process of developing my own MSA and SOW templates.

So seeing this written out in a nice neat list catalyzed me. Here, paraphrased, is what a bunch of allegedly smart people in the US government believe should be defined in your outsourcing contract:

Best practices for outsourcing contracts - the short list:
  • Scope of services to be delivered
  • Performance standards for same
  • Pricing for same
  • Controls
  • Financial and control reporting
  • Right to audit
  • Ownership of data and work product
  • Regulatory compliance
  • Indemnification
  • Limitation of liability
  • Dispute resolution
  • Contract duration
  • Restrictions on / around sub-contractors
  • Termination
  • Return of data and work product
  • Insurance coverage
  • Prevailing jurisdiction
  • Choice of law
  • Regulatory access to data
  • Business continuity planning
The FFIEC doesn't list this, but I'd add:
  • Security restrictions
  • Key staff special handling
  • Non-solicitation
  • Non-compete
  • Insurance coverage
Disclaimer: I am not a lawyer, and this should in no way be construed as legal advice. If you're writing, reviewing or negotiating a contract you should get your company's legal team involved. You can point them to this blog post but they'll probably already know this stuff. And if they're good, they'll have their own contractual boilerplate with this info and a lot more spelled out in that special kind of excruciatingly complex language that can only be written by people who bill by the hour.



20.7.08

Apocryphal or just wierd?


An associate of mine in India asked me recently if I'd heard about some company that planned to anchor a ship 3 miles off the coast of LA, to provide "offshore" engineering services in international waters, allegedly away from pesky things like labor laws and T1 lines.

I strongly asserted that this was a hoax, as I seemed to recall this story popping up every 18 months or so. I'm right about the story popping up every so often, but it's not clear yet that this is or isn't a hoax.

  • This was covered by the Boston Globe in 2005. Link.
  • Network World picked up the story around the same time. Link.
  • Ditto this from Forbes, again around the same time. Link.
The company all these articles reference is called SeaCode. They have a very minimalist web site that confirms the basic approach outlined in the three articles above. They're going to pack a ship with Indian and Chinese engineers, and crank out code 24 X 7.

No mention of how they overcome network access challenges, storms, and the simple logistics of having a ship filled with 500 people, all of who will want to eat and presumably sleep in addition to coding their fingers to the bone.

It still sounds sketchy, but Snopes.com has nothing on it. The Who-Is look up for their domain lists one of the guys referenced in the articles above. So this might be a real thing...

I hope to hear back from them this week. If I do, I'll post an update.

Oh, and I retract my previous statement about this obviously being a hoax. That'll teach me not do to my research first...


16.7.08

A comment on the dangers of machine translation


Given my previous post about localization and translation, I thought I'd link to this. It's a great post from AdFreak. The comments in the thread are particularly good!

This illustrates perfectly why you need a human to "QA" machine translation.


15.7.08

Background Checks

A while back, I posted a brief summary of what I had put in place for background checks. That older post is available here. I continue to believe that it's a best practice to do pre-employment screening for your offshore partners, comparable to what ever your company does onshore.

It turns out that a lot of Indian service firms are coming to the same conclusion.

It's possibly an inevitable side-effect of a booming industry, but apparently a lot of people in India are padding their resumes, or out right fabricating their professional credentials. An associate of mine sent me this link recently, to an article in Rediff:

TCS pink slip to techies with fudged CVs

The article describes verification checks put in place by TCS, Infosys, and Satyam, among others. Here's a brief excerpt:

One in every four CVs received by the IT services firm has some kind of discrepancies.

The article describes verification steps around what people write about themselves in their resumes. That's a little different than US criminal background checks, or credit checks, but it is a good indicator of dissimilitude if not outright malfeasance.

It's a short article, and definitely worth a read.


10.7.08

Blog Roll #2 - Strategic Outsourcing Professionals

This blog contains some interesting and well reasoned essays about strategic global sourcing. The author, to quote the blog, is "Director of Global Customer Care Operations for a large American financial institution and am directly responsible for the outsourcing strategy, vendor management and customer service experience for the business."

This blog is less active than some others I read, but so far I generally agree with what the author posts.

I particularly like his blog entry on managing attrition in offshore customer care / BPO centers.

Read and enjoy.


7.7.08

Blog Roll #1 - Horses for Sources

This is a great forum and blog, written and moderated by Phil Fersht. I first ran into Phil on the Outsourcing forum on LinkedIn, where he frequently posts thought and debate provoking questions. I started reading his blog shortly thereafter, and over the last few months have found it to be a decent, measured source of information and debate.

It has a strong readership, so the comments are interesting. Phil has a full bio on the site, if you're interested in that. Basically, he's an analyst / researcher / thought leader, and his insights and opinions seem sound. He posts a few times a week, so there's usually something new worth reading on a Friday afternoon.

You can find it here. Read and enjoy.



A new feature, more blogs about global sourcing

I read a number of blogs about global sourcing, outsourcing, and global technology management. I'm going to start adding those to the "blog roll" on the right, along with a blog post providing some commentary and editorial, citing why I like the blog, and what I get out of it. Your mileage may vary.


2.7.08

Book Review - Little Brother by Cory Doctorow



A while back, I posted a review of Moneyball, by Michael Lewis. I listed it as a "book review for people who hate business books." I like that concept, and I read a lot of books, so I'm going to try to make this a semi-regular feature of this blog.

My latest book review for people who hate business books is a ringing endorsement of:

I found out about Cory Doctorow through the blog Boing Boing. If you don’t read that blog, it’s worth checking out. The staffers there do a great job of finding interesting tidbits in the giant haystack of information that is today’s Internet. I learn something new there every day.

Anyway, I picked this book up for a vacation read, and finished it in maybe four sittings. It is written for young adults. That's great, because young adults will become adults soon, and they should read this book before they do. But it's also unfortunate, because it will make a lot of people dismiss the book as beneath their concern. That would be tragic, because this book is a young adult book the way The Catcher in the Rye is a young adult book.

Without revealing too much about the plot (which is relevant, compelling and exciting), this book talks about technology and security. It aptly describes reactive security measures as "Security Theater" developed to provide only the semblance of security. It also raises important and unsettling questions about the end goal of security – is it to mitigate and minimize risk, or is it to capitalize on fear and doubt in order to self-perpetuate. (Put differently: You shouldn't take your security advice from the guy whose day job is selling you surveillance cameras, firewalls, or intrusion detection software.)

The premise of the book plays into my notion of how best to approach security – start with trust, verify frequently. Analyze threats, prioritize risks, and then adopt a level of mitigation that lets you get on with your work at a reasonable risk trade off. Obvious caveats apply around the definition of “reasonable” for any given business or company, but that trust but verify script seems a lot more effective than the shut it all down script that gets played out in this book, and to a significant extent in our real lives.

Oh, and if for no other reason, you should read this because it has the best description of asymmetric cryptography I've ever read!