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.


  1. Interesting comments Peter, however, I still think the main point is being overlooked here.

    Today, especially in this time of financial crisis and economic recession, outsourcing portions of business requirements to offshore companies is becoming more & more the norm.

    Greater investment to return ratio, customised teams to perform the work without the expensive permanent staffing & management and a quality control of the product/service that is greatly improving, this fast-growing alternative is showing that what was once considered to be high risk and hard-to-control is fast becoming and alternative that cannot be ignored.

    Small, flexible teams operating under controlled supervision by experienced managers with cultural and technological experience is proving to be a valuable commodity.

    Large software houses are cumbersome with in-flexible internal processes and fixed overheads that must make high margin to cover costs, hence, their products/services prices are greatly inflated.

    One such Swiss based company recently quoted 700 man hours over 6months for development work of a web-based application to the tune of CHF750,000!! Something which an offshore software development company would be able to do for 1/10 of the price (dependant on location and the specifications of course!) and possibly a shorter delivery time.

    These savings are hard to ignore when the financial pinch is being felt everwhere.

    For SME’s and Start-Ups everywhere the question is not whether or not to consider an offshore software development as an alternative to a large, established software house but which alternative to choose from!

    The market is lush with choices for an alternative and many savings to be had. Worthy of further investigation no?

    Val Jelinic

    Business Development Manager
    MNG-Europe SA
    Fribourg, Switzerland

  2. Thanks for your comment, Val. It would have been more germane, though, if it had addressed the actual point of my post, rather than simply touting the well-known and widely accepted notion of development cost savings obtained from offshoring development. This disconnect is especially notable if you represent a vendor in that space.

    The thrust of your comment was that the cost savings are compelling and worthy of investigation. The thrust of my post, however, had nothing to do with the development cost and everything to do with the seldom-seen readiness of internal teams to absorb systems and components built by outsiders (either down the street or across the ocean). I summed up: “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. ”

    It seems that you somehow read my post as categorically opposing offshoring; I don’t, which is why I wrote this post to explain my stance more completely. While I do have some healthy skepticism about offshore development, I have indeed seen it work effectively. Instead, I choose to emphasize the internal preparation needed long before a company can go down that path, because that is a prerequisite that is often missed amid the shiny appeal of dev cost savings.


  1. […] There’s no crisp handoff of new production code to the operations group, and no formal Operations Acceptance Test (OAT).   Putting code into production needs to be a big […]

  2. […] I’ve written before (”Offshore development: target the destination, even if you never go there“), the reality of the CTO/CIO’s life is to be constantly challenged to produce more. […]

Speak Your Mind