There is no doubt that the term ‘offshoring’ is a polarising one. From one perspective it means cost saving and efficiency, from another it simply means job losses. Whatever your own opinion, there is no doubt that it is an ever-increasing trend as more businesses look at ways of cutting costs. And with this trend, it is worth considering whether most businesses really understand what is required to successfully implement an offshoring project. Are they aware of the real limitations and how to best go about it? Are they prepared for what lies ahead? Are they agile enough?
Outsourcing is not a new concept to Australian corporations. Businesses across many sectors have long been open to the idea of transferring functions in order to save money, raising questions such as ‘why carry the cost of payroll and training internal teams when you can outsource to an expert company who have already benchmarked the process?’. As this attitude permeates business circles, outsourcing functions to overseas offshore teams has gradually become more accepted and accessible to Australians. Ironically, it is the relative strength of the Australian economy that is tempting businesses to look offshore. To use a very crude example, when the Australian dollar was hovering around 80 cents against the US, it was around four times cheaper to get software development done somewhere like the Philippines. When the Aussie dollar is around $1 or more compared to the Greenback, as it is currently, it is around five times cheaper to outsource offshore. Speaking purely in financial terms, it made sense to offshore five years ago. Now it makes even more sense.
As well as the increased financial appeal, the nature of the functions being outsourced has changed too. In terms of IT, when it was upgrades, support or integration of brand name software, the specifications were thoroughly documented by the vendors, meaning turnkey IT functions were the most likely to externalise. What has changed in recent times is that core system functions and bespoke development are being sent to international teams. Flowing on from this increased complexity, communication has suddenly become a growing problem and an almost unspoken hidden cost.
At a recent conference attended by senior members of the banking and finance industries, a speaker from one Australian banking institution that had been through the offshoring process was asked, quite simply, if it actually worked. He replied in an exasperated tone; “Yes... now”. Without needing to go into the detail, that short response clearly indicated one of the main problems businesses face when they decide to outsource to international teams: if projects are not planned properly from the beginning, problems will be encountered. Indeed, recent history is littered with examples of companies that have plunged head-first into offshoring projects without taking the time to properly communicate the real requirements. This inevitably leads to delays, budget blow-outs, more resources being pulled in, disruption to other business activities, and so on. Suddenly the financial benefits of cheaper outsourcing don’t seem so clear-cut.
It is too easy and not entirely accurate to believe that communication problems are simply due to language or cultural barriers. It can also be due to proximity. Traditionally, IT teams will have been working together for some time in the same company. They establish an intuitive awareness of who does what and the requirements of particular projects. They will generally be working from the same place, interacting with each other on a personal level, working in unison and changing course together. While the ability to communicate via electronic means is vastly improved, and continues to improve, it is still difficult to replicate the advantage of having a knowledgeable team on site - one that is truly agile.
Agile methodology should be perfect for offshoring. It allows for the local team to work during the day, while at night the offshore team responds to the progress which the local team will pick up again the next morning. In theory, it should be an almost 24/7 cycle of development. Yet, it so seldom works out that way. This is partly due to what was suggested previously - the offshore developers are simply not there with the rest of your team. They don’t know the local processes. In time, they will - of that there is little doubt - but no business can afford to be taking too long to get these processes sorted. Agile, as opposed to following traditional methodology, gives developers the great advantage of being able to roll with the punches and change course when needed. But it does not mean that the development cycle should continue in perpetuity, taking a disproportionate amount of time to achieve a suitable outcome.
What is needed to remedy these communication problems is clarity from the outset. It needs to be clear enough to break through any communication barriers. For example, why solely use text documentation which, by itself, can be open to interpretation? Why not use text and images and wireframes and video to comprehensively cover all aspects of the requirements? Why not create a working demonstration?
A demonstration can illustrate the main objectives of the software from the onset and gives the offshore team something tangible to work with. At GLiNTECH, we believe that all systems should be demonstrable. Creating a demonstration using your local team means that the software development cycle moves towards a more agile methodology. As your local team build out the demonstrations functionality, the rest of the business, including stakeholders and the offshore team, learns to work with you more intuitively. It breaks both the language and proximity barrier by physically showing what is required. In our experience, it creates talking points of what works and what doesn’t more clearly than anything we have seen.
Offshoring is not about simply transferring problems and headcount to an outside party - it is not a cut-and-run solution. A responsible business considering outsourcing is obliged to thoroughly investigate all the limitations and the true cost of the exercise. They should not only scrutinise the offshore company, but also look at the relative strengths and weaknesses of their own organisation to assess what, if any, additional value can be gained. The decision to outsource is no doubt a significant one and you want to be certain that it delivers what is expected. By giving your team the tools to meet the specific requirements, you can demonstrate specific examples, which in turn helps communication and leads to a complete resolution. After all, the failure to properly manage an outsourcing arrangement will only be problematic in the long run and not very agile.