OUTSOURCING LESSONS LEARNED

I've outsourced in India, China, Vietnam and Russia

By Steve Bowler

In the current global economy, and with the tight labor market, outsourcing remains a tool that many will use. The reasons for outsourcing are varied. Some will use it for the perceived lower cost. Some will use it to accomplish a short term objective, like a new product or prototype. Others like the flexibility for short term bubbles in workload. It also may be used for specialties such as testing. So let's look at some of my experiences.

I first gained experience with outsourcing when I jumped into an Internet startup in 2000. The developers were already selected and resided in Pune, India. My boss, the company founder, had a previous relationship with this team. At first I worked with them mostly as a tester but soon also as the product manager. They used a simple browser-enabled ticketing vault that made it easy to share information on bug fix and enhancements. I would find this to be critical to a smooth operation. The time difference was close to 12 hours which meant limited overlap for meetings at each end of the day.

I soon settled into a routine of spending my days reviewing their previous day's efforts, re-prioritizing bugs and tasks for the next day, then meeting to walk through them at the end of my day and the start of theirs. During the time there was limited customer use of the product, this worked well, whereas when customers began using it more and occasionally running into crises requiring immediate attention, there could be issues. Though not an operations engineer by trade, I learned to stop and start web servers, application servers, and databases, and make cosmetic changes. After some time we hired an internal CTO who could do more on his own and I was relieved of technical duties. The resultant product was useful as a 1.0 prototype but not production-ready. Goof enough to get funding and a commercial partnership to build the 2.0.

My next experience with outsourcing was a little different from the first. This time the team was in China. And the CTO, a Chinese engineer, was at headquarters in California while I was in Massachusetts working from home. The users of the system were in Arizona and Oregon. Problems soon surfaced that I didn't have with the India team. First, most of the team including the CTO spoke only limited English. So verbal communications were strained. Next, the CTO was used to working on China time and was only sporadically available during the day. The customers often had serious reliability issues with the product and contacted me for help. It sometimes took hours to find the CTO or anyone in China to respond. I don't know if communications caused poorer quality and reliability of the product but it didn't help and certainly caused a lag in time-to-resolve the biggest problems. To move forward I decided to change teams.

Next I worked with a team in Vietnam. To my delight, they had better communication skills. But we also made a decision to separate the operations tasks like production releases and server monitoring to a company in California. This resulted in a dramatic increase in reliability and improvement in response time. Coders could code and operations would collect completed and tested enhancements and bug fixes and batch them for release. We settled into a bi-weekly Agile release schedule after the crisis had passed. Again, using an online tool for communicating requirements and priorities proved invaluable.

My most recent experience with outsourcing was with a Russian team. This time the technical and project management was out of New York, same time zone as me. But they chose not to share the ticketing system, opting instead to only share a project management tool where the requirements would be stored. This meant we had no visibility into which items were being worked on each day, how many engineers were working, who was assigned what, and what was completed each day. Any issues were relayed via the project leader and then to us. We managed but it felt like 10,000 foot level visibility rather than the 1,000 or 100 foot I was used to. It also had more of a waterfall, large releases, long phases, approach.

So what did I learn?

1. Communications are more critical than ever with remote teams. Requirements must be explicit, usually graphical with screen pics with circles and arrows, and issues must be surfaced and resolved immediately. An online tool (JIRA, Redmine, Bugzilla, Pivotal Tracker) is essential. A Project leader who speaks your language is key.

2. If you go into it to save cost you may end up disappointed. The extra effort you'll need from your VP Engineering and VP Products and operations may wipe out some of the savings.  Done right though it is very economical, especially if hiring cycles are long and labor supply tight.

3. Short releases are easier and more productive. Though there is some overhead penalty for releasing more frequently, having less to test each time is better and if you ever have to revert, not as catastrophic. An Agile approach is preferable to long phases and big releases.

4. The top product and technical persons should be inside the company. The product is the family jewels. Your VP/Director Products should define it and your CTO/VP Engineering should design it, architect it and shepherd it through. Outsourcers should be implementation folks, coders and testers.

5. It doesn't matter where they are or who they are but managing time zones can be challenging. I conducted many a meeting from home at 5 a.m. or 11 p.m. Of the four countries I did business with I wouldn't exclude any. The Chinese team was the most difficult but not through any particular fault of their own. Had they adhered to the advice above it would have worked out fine.

6. The 24 hour cycle can be very productive. Not being interrupted all day and only meeting at the beginning and end of the day becomes  very useful cycle. I got so I preferred it.

7. Keeping an eye on budget can be challenging when not onsite. We were once charged for a coder who had moved on from the outsourcer months before. I would recommend deliverable based billing with deadline based incentives or penalties. Simply paying for effort over time can lead to missed milestones and conflict.

In summary, outsourcing is a useful way to get a product built. It overcomes issue with a tight labor supply, burdensome visa management, and the need to rapidly expand or contract your workforce. But is has to be managed tightly.

Steve Bowler is a Co-Founder of HotChalk, Inc., Inc. an early pioneer in K12 EdTech and an Online Program Manager for Post Secondary Education. He also Co-Founded ProductFactory, Inc., a provider of enterprise Product Portfolio Management that was acquired and a Founder of Venalytica in Consumer Preference Analytics. Steve is an expert in Product Management, Program Management and Agile Development.