Using outsourcing effectively

There are plenty of stories available online about outsourcing projects that failed to live up to expectations.  Yet I see very few explanations as to why such failures occur, and more importantly, how to prevent a similar failure from happening again.  While I'll be the first to admit I don't have much experience with outsourced projects on the scale that usually make these types of headlines, I'd like to offer some advice on how to outsource effectively, from the perspective of a consultant who carries out outsourced work.

Before I get too far into that, though, I'd like to discuss the difference between outsourcing and off-shoring.  Outsourcing is the process of moving one or more business functions to an outside company, likely a specialist in that particular function.  Off-shoring is the process of moving a particular business function to another location outside of your current company, typically to a country with less expensive labor.  You can have one without the other, or do both at the same time.  I will stick to outsourcing for now and leave off-shoring for another time.

If you’re outsourcing the development of a computer application, you will help both yourself and your vendor if you start by getting as good an idea as possible of what you want out of your application.  Most vendors should expect that you will change your mind about some of the application's functionality during the course of making the software; unfortunately such "scope creep" is an expected part of building software.  However, requirements that are too vague will make it extremely difficult for your vendor to build what you want.  If you know you will have trouble making requirements, hire someone who will help you discover and articulate them.

It is also important to determine where your priorities lie.  Everyone wants their application done quickly, at a low cost, and with high quality.  To make matters even more unclear, "quality" can take on different meanings to different people.  Application speed, ease of use, application up-time, number of bugs, scalability (i.e. the ability for the application to grow with few growing pains), ease to add features, secureness of the application, etc., can all contribute to the perception of "quality".  Unfortunately, many of these are conflicting goals.  Making an application execute very quickly takes longer to develop and is more expensive to build, just like adding a large number features can make your application harder to maintain.  You and your vendor should be on the same page as to where compromises must be made.  Be sure to communicate these goals and make sure your vendor follows them.  Communication up front along these lines can save a lot of headaches and discussion when the bill arrives.

One thing that will help you and your vendor manage your project is to break your large projects into smaller, yet still useful, chunks.  More often than not, once a client starts working with their application, they discover that some of the ideas generated don't work as well in the application as they do in the planning stages.  If you try to develop too much at once, problems are identified late, and the later a problem is found, the more expensive it is to fix.  If you start small, you will see the results of your work sooner, allowing you and your vendor to adapt to each other's styles.  This will allow each of you to communicate more effectively.

You may want to consider billing your projects on a time and materials basis only.  Fixed bid projects are tougher for both parties.  The outsourcing company very often tries to put in as many features as possible in an effort to get the most for their money.  This can cause the company to lose focus on their core needs from the software.  The vendor must protect its interests, and therefore cannot be very open or cooperative to change requests.  If a project is billed on time and materials, a company can focus on which features/changes are most important to them, and the outsourcer can focus on how to most efficiently fill these requests.  In other words, the discussion turns from extracting the most value possible from the other company in a fixed-bid situation to a more cooperative effort to build the best software possible in a time and materials situation.

Also, be sure to stay active in your project.  You may be tempted to give your vendor all the information you think he or she needs and then let him or her finish the project, but that's usually a recipe for failure.  Review any documentation, samples, code, beta versions, etc., as thoroughly as possible.  Your vendor should have tried to understand your needs, but something inevitably gets lost in translation.  Be sure to voice any concerns early before they become problems.  The sooner you find errors or omissions, the cheaper and easier it is to fix them.

Most of these suggestions come down to improving communication.  Understanding your project and understanding your priorities help you give clearer directions to your vendor as to what you want from your project.  Breaking down your project into smaller, but still useful, chunks helps you and your vendor communicate requirements in a meaningful way.  Billing your project on a time and materials basis help you and your vendor communicate about what the project needs, rather than about unnecessary information.  Keeping communication clear, open, and frequent will help increase the odds of success in any of your outsourced projects.