Lesson learned for small businesses looking to outsource

* An outsourcing contract that went awry and what we can learn from it

It seems that stories of outsourcing failures are more common than those of outsourcing successes. This may be because everyone likes a good war story and likes to hear about the pain of others. And it is still more fun to learn what not to do by hearing about what went wrong in someone else's deal. So in that light I want to share a story about a small software company (fewer than 50 people) looking to improve its quality assurance (QA) function through automation.

Since the company had no internal experience with QA automation tools it decided to consider an outsourcer to bring both resources and experience to the table. As a small company, it was constantly receiving marketing information for offshore outsourcing companies - the little no-name guys, not the big names we all know.

The software firm went through a thorough procurement process, clearly identifying its requirements and checking references on the shortlisted vendors before making its final selection. During the procurement process, the software firm was impressed with the experience of some of the resources that would be working on its project, and made its decision in part because of the people who would be involved.

So far so good, but here comes the twist. As the project began, the company was presented with different people to work on its project as there were conflicts with the people they had met previously. The new on-site people turned out not to have the domain experience required for the job, namely experience with QA automation tools. This outsourcer seemed to need to be told step by step how to do the project rather than show up with the answers, which was a key reason the vendor was hired. Needless to say, this project was off to a bad start and it didn't get better over time. Following is a few more of the problems that plagued this relationship and doomed it to failure:

* The outsourcer was having trouble finding qualified resources to put on the project (lack of experienced resources was one of the primary reasons the work was outsourced in the first place - the outsourcer faced the same issues as the client).

* The outsourced test team turned up many defects that were not really defects - it just didn't understand the application well enough and ended up taking longer to sort out non-defects than when testing was done in-house by the client.

* The outsourced test team failed to discover new defects; the results were not reliable and real defects were missed.

* The outsourcer was too eager to please and didn't raise issues or problems along the way; it just kept working hard to accomplish the task. By the time it was obvious that there were problems, the project was off schedule.

Today this small software company has decided to use local contractors under its direct supervision to accomplish the automation task. This is working out much better. My contact at the company says these resources are more accessible, easier to communicate with and they are gaining the required experience as the project progresses.

I do not think the problem with this story lies in the act of outsourcing, but in minor misses in the decision-making and contracting phase. Several things can be learned from this to ensure you don't end up with a bad outsourcing relationship.

* Don't fall in love with the "A" team and end up with the "C" team on your project. For long term projects, and particularly projects with the bigger name firms, it can be difficult to get them to commit to which people will be leading or working on your project. However, you should negotiate hard to know who will be in key positions for your project and have some say over changing the person out if they are not working out. For shorter term projects, you should be able to specify that the person you worked with in the sales cycle will be on your project.

* Reference checks are nice for learning if a vendor can please a client, but do not count on this to ensure their domain expertise unless the reference projects are very close to what you are looking to do. For very specific domain experience, such as the QA automation in the above example, be as diligent about the experience of the resources the vendor will put on your project as you would if you were hiring them. Domain experience can make or break many projects.

* Communication seems to be much smoother when key resources (project manager, architects, etc.) are on-site with you, and these local resources can work as part of your team and maintain the communication responsibilities to the offshore resources. This will shelter you from the fact that a big part of the team is elsewhere.

* The big name firms have a big name for a reason - they have a longer track record of success and now have more depth in their team to serve you. While I have worked in many start-ups and do not like to have to sell around the advantages of a bigger company, the fact remains that bigger companies are likely a safer bet.

Be clear about the skill sets you need from the outsourcer, ensure they have the domain experience, and have a local team at your site and you can find great value in an outsourced relationship.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2006 IDG Communications, Inc.