Co-learning in the offshoring of software development

Man in water The transitioning of software development activity from organisations based in developed countries like the UK is potentially a major source of competitive advantage for those organisations, Christopher Williams looks at some of the issues.

As many have noted, the difficulties of managing remote teams based in far-flung locations such as India, China or Eastern Europe can adversely impact the productivity of the software development function, and thus erode any advantages gained through cost-savings.

This is especially true when the remote team contains individuals who are not 'captive' employees of the focal organisation, but, as in the case of outsourced offshoring, are actually employees of an offshore provider.

Such difficulties include the lack of understanding that offshore teams have regarding their client's business context, and the sometimes aggressive resource rotation policies of offshore providers that result in key team members moving to different projects, possibly with different clients, at short notice.

Overcoming such problems - whilst simultaneously trying to maintain the same level of quality in software deliverables - is a key challenge for onshore project managers. This challenge is made harder when senior management expectations for software development productivity do not change accordingly.

Onshore project managers have been confronted with this demanding situation in recent years. But, more often than not, they are ill-prepared to manage ongoing software development activity, whilst, at the same time, transitioning technical and business knowledge to people they have never met.

Offshore team members have generally never been outside their own country of origin, may lack soft skills and innovative capabilities, and may require additional monitoring and performance management, especially during a transition period.

So what has been happening? How has the software development function survived the wave of offshoring that has swamped organisations of developed countries in recent years, and how have onshore project managers coped with this new challenge?

The answer lies in learning, in particular, in the joint learning - or co-learning - that both offshore provider individuals and onshore client individuals together undertake in the context of specific projects.

Firstly, the efficiency with which an offshore team is able to learn from an onshore team sets the initial conditions on which future success will depend.

Such learning does not only relate to the specific technologies (normally) specified by the client (such as programming languages, database platforms, methodologies and so on) but also to aspects in the business context and history of specific projects.

Design decisions made during the development of legacy systems are often still relevant, lessons learned from past projects before offshoring came along can still be very useful and an understanding of how users will interact with - and leverage - a system in its final organisational setting, will all constitute useful knowledge that an offshore development team should not ignore.

Such nuggets of knowledge are often badly documented and not readily available to an offshore team at the outset of the transition of software development activity. But they become clearer over time, and they are absorbed and assimilated by an offshore team over time.

One way in which this happens is via the direct feedback given by onshore project managers to offshore individuals when poor quality deliverables are provided by the offshore team.

Frequently, the root cause of poor quality deliverables during an offshore transition, especially in the early stages, is the lack of understanding in the offshore team on the wider business and historic context of a system, the reasons for certain design decisions and the idiosyncratic behaviours of end-users. Offshore team members are, in this respect, thrown into the deep end without clear orientation. So direct feedback on their mistakes is vital.

A second way in which an offshore team is able to gain the broader insight required to optimise the quality of their deliverables is by placing some of their own team members onsite into their client's organisation.

This, of course, requires the agreement of the client, due to cost implications. But this embedding of offshore personnel can greatly enhance the ability of the remote team to understand and appreciate the environment, strategy and structure of their client.

It can act as a very efficient way of overcoming the communication and cultural barriers that prevent important pieces of knowledge to flow from an onshore team to an embryonic offshore team.

The selecting of individuals by the offshore provider to carry out this role would ideally be based on an ability to interact, engage and socialise with client project managers, and possibly end-users.

Such individuals act as conduits of knowledge between the client and the offshore team; an important channel by which remote staff learn. They are also themselves able detect and correct issues with quality and timeliness of deliverables.

To give the new offshoring arrangement the best chance of success, the onshore client team, has to adapt and learn too. The type of new knowledge that the onshore team needs to absorb and assimilate is, arguably, more tacit and 'uncodifiable' in nature, compared to the type of knowledge the offshore team requires.

There are two main reasons for this: firstly, the onshore team has relinquished ownership of software coding and core software development work to an offshore provider, and secondly, the offshore provider team may not respond to the same project management control and communication mechanisms that were previously in place. Let's looks at these one at a time.

The relinquishing of the coding task inevitably means a re-focus by the onshore team on the broader aspects of the software development lifecycle. These include, for example, translating requirements into task specifications and work package definitions that are both comprehensible and comprehensive enough for an offshore team to be able to perform in a black-box coding role.

Because previous requirements could be communicated easily and directly in a face-to-face interaction with a developer who is perhaps well-known and well-socialised with the business analyst and broader organisation, communication could have an informal as well as a formal component.

Within a new offshoring arrangement, a shift to a more formal description is needed, but one in which the onshore analyst has to pro-actively and continuously ask two questions: Does what I'm writing truly reflect the organisation's needs and goals? and, more to the point: To what extent will my offshore team really understand what I’m writing? Thus the onshore team has to sharpen up its ability to articulate its 'taken-for-granted' assumptions when driving a new offshore team.

In terms of control and coordination, the onshore team also has to learn new skills and develop different behaviour. At a basic level, the quality of telephone conversations and video conferences may hinder the communication of requirements and feedback to offshore teams. Onshore teams need to learn how to actively listen to individuals whose English is not their mother language, doing this quite often over acoustically poor telephone lines.

At a deeper level, onshore teams need to learn how to recognise when offshore individuals have not understood a message, however trivial. Unless the offshore team is asked to repeat and demonstrate that they have understood a message, there is no guarantee they really have received the message.

Video conferences where offshore team members nod their heads, yet on being pressed clearly have not got the point of a conversation, are very costly. Onshore teams need to develop a good sense of assessing whether knowledge has been successfully transferred.

These examples are by no means exhaustive. But they do suggest that the key mechanism by which the software development function can continue to deliver at the same level as it used to, whilst simultaneously undertaking a transition of software development to an outsourced offshore provider, is by a mutual adjustment process. It is a co-learning by both the organisation's own onshore team members, as well as by the offshore provider's team members.

The efficiency of this co-learning is vitally important to the success of the software development function going forward. For any given organisation or project, co-learning during offshoring will ultimately determine the quality of software deliverables, not just in the short-term, but also in the years to come.

Christopher Williams MBCS has worked in the field of software development in technical, management and consulting roles since the mid-1980s.

© Christopher Williams

14 March 2007