I run a lean, mean cloud integrator with a background in software development. We took up offshoring as a great option to not only to increase our scale, but get more done faster and more cheaply. Like many, we envisaged offshoring to be a ‘cheaper’ option to onshore development.
Luckily, we got some things right, but we also got some really wrong. The following are some notes from the field so you can perhaps learn from our battle scars:
Read more about IT leaders in CIO Australia’s Globalisation category.
Firstly, offshoring is not cheaper. It may seem so, but it’s going to mean wrapping each project in far more precision, documentation and rigour than one where you can quickly communicate with the development team.
We haven’t found offshoring really suits agile and innovative development. Certainly, our core product is all developed in-house. For customers after a standard website with database or a simple line of business application, however, the whole process can work well.
Be aware, once you start down the road, that a plethora of potential partners will email you day and night bidding for your business. Each of these, in our experience, offers a low cost or free first engagement and then seem to increase the cost and decrease the quality over time.
We considered hopping between free first time providers for all our projects, but that approach seemed a little unethical.
You need three main levels of interaction with an offshoring partner. One is business related: How much, what are the milestones and how do you pay? We’ve learned not to let our developers manage the negotiation as they feel sorry for the poor offshore developers and don’t generally drive as hard a bargain as they should!
Once you have one or two good providers, stick with them, but always let them compete for work. We have found it the best way to ensure a good price and, funnily enough, it improves the quality of the deliverable.
Secondly, specifications need to be tight, accurate, discussed and agreed by everybody. Most offshore providers will deliver exactly what you specify. We also add our coding standards to the specification. It’s funny how adding these standards really helps the end product. Scope and price go hand-in-hand, so be prepared to go back time and time again to get what you specify (and, commonly, not to pay for it).
Finally, our lead developers project manage the offshore developers as if they were in the same team. We’ve found it to be the only effective way to get what we need done. Project managers, business analysts and team leaders don’t seem to be able to communicate as well as our developers do.
Be prepared for things to go wrong. We have seen fantastic solutions and woeful ones, from the same provider and at the same time. Despite this, most of the time we have achieved a good final result, nicely on budget with acceptable quality.
A good CIO can effectively create development scale by blending offshore development into existing development teams. We’ve certainly found this to be the most effective. Offshoring can also let your internal developers focus on where the business value is, leaving it to the offshore developers to undertake the rest of the work that ties it all together.
In general, most functions can be outsourced, but be really careful never to outsource your core business. If your core business is customer care, it should really be internal, not in Manila. If your core business is product development, most of it should probably be in-house. Most of our core IT systems are in the cloud so we don’t manage them ourselves. It allows us to focus on our core business rather than running internal IT. Our consulting business, however, is all onshore because that’s our core value proposition.
Nick Beaugeard is the managing director of HubOne, a cloud integrator. He has held various senior roles in the Australian and British IT industry
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.