The pitfalls of the implicit “buy” bias for IT systems and services

I wrote last time about how there are twin truths to the buy vs. build dilemma: outsourcing can be a superb way to leverage external expertise and keep your own team focused on core functions; yet, outsourcing is not an easy or friction-free choice, and it’s easy to simply substitute one set of problems with another.

Note that I’m not specifically addressing offshoring here; rather, my comments pertain to any time you engage an external entity (across the big pond or across town) to perform a development or operations task instead of using your own people. I’ll have more to say about the specific subject of offshoring soon.

As Scott McNealy basically challenged Bill Howard at Sun, why not outsource (i.e., buy) everything and build nothing yourself? If that’s now the implicit going-in position regarding IT systems and services for many of today’s executives, then here are a few important (and often overlooked) things to consider, pitfalls of the “buy” side of the equation:

• Figure out your desired core competencies, as a company and as an IT organization. Focus on outsourcing/buying the fringe, not the chewy chocolate center of your total areas of responsibility. For example, at a recent job where the principal operational responsibility was running the company’s social networking web site, I made the decision to outsource internal e-mail, rather than host our own Exchange server, etc.

• Another way to put it: avoid building “plumbing”, even though it’s (maybe) considered fun or cool by your development team. If you’re a retailer, for example, you don’t want or need to be building generic middleware software components that are readily available elsewhere. I once saw a big consulting firm, left to their own devices, sink literally millions of client dollars into constructing and tweaking an elaborate bug tracking spreadsheet (yes, spreadsheet), rather than put a part of that effort into identifying and buying an adequate off-the-shelf solution. A classic example of yak shaving, that… not to mention client bilking.

• Don’t let anyone assume (and frankly, your senior execs are classic candidates for making this assumption) that outsourcing a given area will mean no resource commitment or involvement on your side. Outsourcing is meant to be a case of leveraging, and it can never mean throwing up your hands and absolving the company of any responsibility or involvement.

• Make sure you (or someone else at the company) can be a tough and active negotiator, both on price and on terms and conditions. Mistakes made on either one can affect the bottom line for years.

• In the case of one-off projects (as opposed to outsourcing ongoing services), watch out for inadvertently creating a total, ongoing, interminable dependency on the entity to which you’ve outsourced. Keep some employee skin (i.e., familiarity) in the game.

• It’s really rare for a system or service to be truly stand-alone, in any company. Assume that at least 30% of the total schedule will require intense participation from your internal resources, carefully defining integration points, clarifying requirements, and ensuring knowledge transfer.

• Try not to outsource all the most enticing projects, for the sake of your internal team’s interest, pride, and eventual continuity. In fact, be sure to make it clear to your team, when you do outsource something, why you picked that specific area or project.

• Think about the state of your operational acceptance process. If you haven’t had a robust process for migrating new applications or builds into production, that process needs to be crystallized before outsourcing anything is remotely viable. You do not want to get into the situation of having the outsourced entity have to ship an engineer to your doorstep to install its product into your production environment. If you can’t succinctly state the specific hand-off requirements to your vendor up front, then trouble is down the road.

• On outsourced development projects, unless it truly is a stand-alone project (a rarity), think about your integration test environments and process. Where will the acceptance gates be? You’re not really contemplating just taking their word that everything works and won’t impact your other applications, are you?

It should be clear from the above that outsourcing entails a ton of work on your end, work which can come close to balancing out the actual work you’re supposedly outsourcing. But here’s the most important point: you should be doing that preparation work anyway, even for internal projects. You should have acceptance gates, clear hand-offs, careful integration testing, etc. If you organize and plan for that, you have the ability to scale your team up internally as well as externally. You can then do a kind of “internal outsourcing” on a project-by-project basis, since hand-offs are crisp and safety nets are in place. That approach ultimately becomes the only possible meaningful answer to the recurring dilemma I’ve written about before: how do you stuff 8 pounds of manure into a five-pound bag.

Bottom line: if you’re robust enough already in your organization about these “best practice” kinds of hand-offs, you’re quite ready to shade the “buy vs. build” equation a bit more towards the “buy” side. If you’re not, you should be devoting night and day to getting there, for internal quality and scalability reasons alone.