Five Tips for Software Outsourcing

Insights

Access to global talent pools, potentially at lower hourly cost than at home, makes it likely that you will be looking at outsourcing as a way to stretch your software development investment. Cheap labor alone does not guarantee better value per dollar. If you want to get the most from adding outsource developers to your mix, read on.

There are many reasons to consider outsourcing as an adjunct to in-house software development. Outsourcing gives you access to global talent that may help you scale more rapidly than if you are restricted to a local labor market, and can allow you to add new skills quickly. The usual motive though is to save money with a lower-priced labor pool. The unstated assumption in cost reduction is that cheaper labor will deliver more value (or profit) per dollar invested. This is not necessarily true. A more precise objective is to improve quality adjusted value delivered to the market per dollar invested.  

What if my whole dev process is outsourced? (I’m a startup)

5 tips - augmentation, beginning:

  1. Augment existing teams rather than having outsource teams act standalone

  2. Integrate fully. Outsource people use the same interactions, processes, and tools that employees use.

  3. Budget for supervision and acceptance. Employees who understand the product and market work with outsource partners to develop stories, interact frequently, and check the quality of work.

  4. Manage Time Zone and Turnover; be aware of culture.

  5. Measure the results

5 tips - midstream (already outsource and have in-house devs)

  1. Timezone and turnover

  2. One system for all work

  3. In-house staff to do PM, PO, program management, and acceptance testing

  4. Manage to quality adjusted value delivered

  5. Chef does the dishes

5 tips - virtual, beginning (startup)

  1. Time zone 

  2. Turnover, Know who you are dealing with, plan for overlap

  3. You are responsible for understanding your customer and market

  4. You are responsible for making sure the software meets market needs

  5. Integrate fully, and expect transparency and collaboration

Before taking on outsourcing (or concurrently if you have already started), look hard for ways to improve the delivery effectiveness of the team that you have. Bad habits that are in place now may worsen when you scale up or outsource.

Here are some practices that can help reduce the risks:

  • Start by using outsource people as adds to existing teams (given modern remote working tools) rather than trying to create a self-sufficient outsourced team and lead it remotely. 

  • Integrate fully with your development tools and practices, including your work tracking system, version management, build, email, remote collaboration tools, and your Agile development practices. One way to do and track all the work.

  • Outsource in or near your Time Zone if possible. If you are already global, then align outsource people with employees who are as close as possible to the same TZ. If you must outsource to a remote TZ (anything more than 4 hours), consider having at least one leader from the outsource team work at your site or on your TZ to act as a bridge to the remote team so there is more time for interaction.

  • Watch turnover carefully. Ask outsource vendors to report on turnover regularly and manage it to levels that you consider acceptable (under 10%)

  • Interview carefully and to similar standards you would use for employees. Proficiency in spoken and written business English mandatory (for companies whose main language is English)

  • Outsource developers do not know your business at first - they will need to learn what matters just as an employee would. You will invest in them, so interview carefully and minimize turnover. They will need at least as much time to become productive as a new employee would, possibly more if they don’t get the same mentorship and attention.

  • Consider integrating local time zone outsource developers into existing (employee) scrum teams for cross training.

Inspect work product at sprint boundaries. Recognize that you have to allocate leadership capacity to doing this.

Companies usually begin outsourcing software development to gain access to a lower cost labor pool than they can get domestically. Please keep this in mind: cheap labor is not sufficient to improve your software development productivity per dollar invested. Think carefully about what problem you are trying to solve and what new problems outsourcing might entail. 

Other reasons for outsourcing include:

  • Ready access to a global talent pool

  • Grow or shrink R&D spend more rapidly in response to economic changes

  • Add new skills quickly

Caution aside, outsourcing is here to stay. So here are some things to consider in order to make the most of your outsourcing investment

Software is all about context. Developers need familiarization time on a new assignment before they become fully productive.. This may include the programming languages involved, the toolchain, any coding customs observed by the team, the existing or legacy code base and how it works, the development approach, and something about the end user and how they will use the product or service. It is not unusual for it to take 3-6 months for a new developer to become fully productive on an assignment. This is especially true if the new developer will be fixing bugs since this puts a premium on knowing the code base.  For these reasons it's important to consider the cost of turnover. If it takes 6 months for a developer to become productive, we might guess that each new hire will cost 3 months' pay to get started. 

How do we account for the gap between a productive developer leaving and a new developer starting, and the extra load on the remaining devs of training the new kid?

Time to hire, time to start, turnover rate

The naive approach to outsourcing is to assume you are "procuring" software the way you might procure a commodity part: Send a detailed specification out for bid, pick the lowest cost bidder, get the result, and use it. No problem, right? This takes everything that is problematic about waterfall development and adds further handicaps. (For more on what's wrong with waterfall, see my essay "W4 or What's Wrong with Waterfall?")

  • You cannot write a perfect specification, and you can't test it either. User needs are hard to characterize and they change over time. The only general way to validate the specification is to make the product and test it on real users to confirm that it is fit for use. So the specification can be wrong there is no good way to know before you write the code. 

  • Things change. The longer the project runs, the more things change. If change is not built into your outsourcing assumptions, then you are exposed to higher costs than you planned. If instead the outsource vendor is solely responsible for the cost of change, you are likely to get padded bids or worse, a vendor who walks away from an over budget project.

  • You need to reserve capacity to test the result - this is often significant compared to the dev cost, and if you outsource the test, who will test the testers?

  • Taking this kind of hands-off approach to development exposes your system to the risk that the outsourced code is unfit for use and will have to be rewritten causing delays to the overall program

What do you need to keep in mind to make the most of outsource talent?

  1. Consider what problem you are trying to solve by outsourcing, and what new problems outsourcing may entail. 

  2. Cheap labor is not sufficient to improve your software development productivity per dollar invested. Model quality effects, turnover, and in-house leadership and acceptance costs into your outsourcing projections, then measure actual results and focus on continuous improvement.

  3. Contract-driven sourcing that relies on detailed plans and specifications is failure prone for software development. This is not new information. Learn from Toyota and other lean pioneers how to build flexibility and collaboration into your outsourcing. 

  4. Consider timezone when selecting outsource partners. There must be substantial workday overlap between the outsource people and the employees who lead them, or productivity and quality will suffer.

  5. To be productive, contractors must learn your software and something about its use. This is especially true of legacy and specialized products. Budget the time appropriately. 

  6. Manage turnover. Turnover rate multiplied by startup time is a “tax” on your outsource labor rate. 

  7. Use the same work tracking tools and practices that you use at home so you have a clear view of how work is progressing. Allowing contractors to use isolated or duplicative systems creates fog and manual work, increasing cost. 

  8. Budget adequate Product and QA/test capacity to lead and accept outsourced work. You are likely underestimating 

  9. Automate testing as an ongoing investment, and measure coverage. 

Cheap labor alone does not guarantee better value per dollar.

A more precise objective is to improve quality adjusted value delivered to market per dollar invested.