Offshore development: aim for it, even if you never go there

As I wrote last time, a large part of my reason for opposing offshoring is because I’ve rarely, if ever, worked in a company where I felt the necessary prerequisites were in place to be able to even consider offshoring as a viable option. Let’s go into that in more detail now.

I’ve observed before that managing the incoming flow of projects is often reminiscent of trying to stuff eight pounds of manure into a five-pound bag. In other words, you have more to do than you could ever get done. You will constantly be challenged, and should be challenging yourself, to find ways out of that dilemma: either, how can you become a better stuffer, so to speak, or, how can you expand the size of the bag itself. I assume that you’re doing everything you can to maximize the effective allocation of your resources so that you are more efficiently stuffing the bag. So, what about increasing the size of the bag? Well, additional internal headcount is usually hard to come by, and it also takes a fair amount of management overhead to scale a department prudently. The push is usually for short-term delivery of a project; increasing your own headcount can work in the long run, but almost never in the short term (read Fred Brooks’ classic The Mythical Man-Month).

But there’s another way. The main insight here is that your ticket to expanding the bag consists of finding a viable way to outsource some projects. I’m not even talking about offshoring here, simply about being able to take a chunk of your project load and hand it to an outside entity to get done. If everything could truly be done that way, then you’d be constrained in your project load only by available money. Sadly, in many shops, almost nothing can be done that way, due to too much interdependency of systems, too much background lore required, and no processes in place to allow for external entities delivering changes into current production environments. My position here is that it’s a key part of your job to change that situation: to work actively on decoupling the interdependencies so that you at least have the option to leverage outside help more effectively.

It’s hard to speak specifically to how to decouple the system interdependencies (every shop will be different in this), so I’ll focus here on something else that will essentially push you down that road. And that’s the notion of establishing crisp handoffs between phases.

Whether you outsource a project to a boutique consulting firm down the street, or to a larger entity on the other side of the globe, you’ll need to have certain practices and processes in place in advance, to have a prayer of succeeding. What happens in most shops, as they grow from early stage startups into even mid-level mature companies, is just the opposite: either extremely casual handoffs into production, or essentially no handoff at all. It all seems to work pretty well (usually), people tend to feel; why change it?

To get what I’m talking about, imagine a world where a vendor has magically produced exactly the code/functionality you need to satisfy some long-sought business need, something you haven’t been able to find the resources and cycles to work on internally. Do you just let them install it into your production environment? Of course not. You’d probably set up some meaningful criteria and deliverables they’d need to meet first, in order to mitigate the numerous and considerable risks and to boost your confidence that everything will go as planned. Those hurdles, handed over and accepted in a formal meeting, are what is known as “entry criteria,” an often-new concept to a lot of shops. They might include things like the items on the following non-comprehensive list:

• Installation instructions and scripts
• Operations guide, including troubleshooting steps
• Documented test results
• A list of known outstanding issues/bugs
• Verification tests to be run post-installation
• Full rollback steps
• Oh, yes: the code/binaries to install

I’ve seen a lot of internal development teams provide little more than just the last item, and, what’s worse, those shops typically have the developers install it.

If you focus your development team on what should be a best practice anyway for internal projects (thinking about future operability; documented installation steps; packaging of deliverables; verification testing, etc.), and expect your operations folks to insist on formal handoffs, you’re paving the way for future handoffs to come, potentially, from points outside your department. You’ve then federated and expanded your development factory, while keeping control over what matters: maintaining a robust production environment. You’ve set standards and expectations in place that you can communicate to outside vendors. Voilà: you’ve expanded the bag (well, at least theoretically).

So here’s my point: creating crisp handoffs, per the skeleton outline above, is something you absolutely must do if you ever hope to outsource. But, you’ll find that you’ll reap significant internal benefits from doing it anyway. Plan to do what’s necessary to lay the groundwork for outsourcing, even if you never actually go down that path.