For ComputerWorld's Seven deadly sins of outsourcing, here's an eighth

ComputerWorld tapped IT vets to come up with The Seven Deadly Sins of Outsourcing.  Nice timing, given that ZDNet launched a piece on the 15 IT Commandments and then subsequently updated it with 12 more (from readers) in the last couple of weeks.
Written by David Berlind, Inactive

ComputerWorld tapped IT vets to come up with The Seven Deadly Sins of Outsourcing.  Nice timing, given that ZDNet launched a piece on the 15 IT Commandments and then subsequently updated it with 12 more (from readers) in the last couple of weeks.  According to the CW story, "More than half of outsourcing agreements end up prematurely terminated."  Avoiding such disasters, according to CW, means knowing what the sins are, and leveraging them as virtues instead of vices.  The story relies on real world failures to drive its points home.  Wrote CW's Judy Artunian:

....after Dell Inc. outsourced its technical support to offshore providers, the company was inundated with complaints from U.S.-based customers who reported that they couldn't understand the service providers because of their accents. Dell had to move a chunk of its technical support services back home to Texas.

CW's sins are:

  1. Feeble governance
  2. Overblown expectations
  3. Blindly banishing projects
  4. Dumbly disowning projects
  5. Bad assumptions
  6. Sloppy service levels
  7. End game myopia

I think I'd add an eighth for good measure: Lack of a hands-off list.  The hands-off list details those parts of the business that cannot, under any circumstances, be outsourced without sign-off from a C-level executive.  We've hosted the outsourcing debate many times here on ZDNet and  I've been chastised on ZDNet for being too outsourcing-happy.  Readers cite huge cost differences when insourcing customer relationship management with open source solutions like SugarCRM versus outsourcing to something like salesforce.com.  Particularly when it comes to smaller companies with low budgets.

But, in the course of running Mashup Camp (for all intents and purposes, a small company with a low budget), Doug Gold and I hit a point where we were in touch with more than 1000 people on a regular basis.  Between his email system, my email system, and a bunch of spreadsheets, it wasn't long before we lost track of which attendees had their questions answered, which didn't, which were coming to an event, which cancelled, who signed up themselves along with six other people but didn't supply any contact info, etc.  It was a mess. 

So, we needed a better way to collaborate on contact management, and now we're playing around with salesforce.com to see if it meets our needs.  Since Mashup Camp is free to attend, we're not using salesforce.com in the traditional sense of selling.  But its basic structure in terms of tracking contacts, categorizing them, tracking our contact with them, and mapping them to events ("campaigns" in salesforce's parlance) could end up covering our basic needs. 

Sure, we could insource CRM.  But we're already insourcing installations of MediaWiki, WordPress, Apache (for Web serving), and email (about to get outsourced too).  And, while we haven't had any IT nightmares yet, working with an outsourced solution feels far more stress-free than working with the insourced ones.  Upgrades? Don't have to worry about them. They'll just happen.  Backups? Covered.  Hardware administration? None.  IT staff? Not necessary (for the CRM solution).  Support? A phone call away.  Software installed locally? None if you want.  We're testing the Outlook plug-in that funnels emails into salesforce for tracking purposes (eg: did we acknowledge that attendee's email?) and we might try the synch option (for synching contact and task data between salesforce and Outlook).  

CRM as a function is separate enough from our other mission critical systems, but complicated enough (in terms of it being enterprise software) to warrant as headache-free a deployment as possible.  Our hands are already full in terms of insourcing the other systems.  And, if we need to mashup the outsourced CRM with the insourced wiki  (for example, if someone emails us with a cancellation for an event, an update to the appropriate campaign automatically cascades into an update of the online attendance list), salesforce has APIs that allow us to connect it to our other insourced systems.

Should we be outsourcing the currently insourced systems?  The thought hasn't escaped us.  As said earlier, email is on the outsource list now that Google is beta testing free email hosting (under your domain).  Gmail doesn't work very well with Eudora (the email client that Doug and I originally used).  But, to test the email integration in salesforce, we made the switch to Outlook (the only supported email client) which does work reasonably well with Gmail.  So, outsourcing the email function is more of a sure bet.

One reason we're insourcing the rest of the systems (actually the hosting of them is outsourced too) is that we're looking to deploy a user-centric identity system like the Higgins Trust Framework (HTF) and we'd like to be able to mash that up with the wiki.  For example,  attendees mantain their personal profile somewhere else on the Internet and, via HTF, contextually release specific subsets of that profile data to mashupcamp.com in such a way that registering for an event doesn't require the re-entry of profile data that attendees are already maintaining somewhere else.  In order to try stuff like this out, some low-level work on the wiki may be required which in turn means that the wiki could very well be on the hands-off list.  We'll know more as we head down the path. 

Editorial standards