Yesterday I had an intense meeting with a former colleague (now a friend) who is wrestling with a product offshoring failure. Unfortunately, when it comes to offshore product development, nobody talks about their failures publicly. It results in the informal knowledge staying in the heads of a few people. This hurts everybody (see point #4 in 5 Reasons Why R&D Offshoring is Maturing So Slowly).
Despite my desire to see a more public discussion of failures, I am not going to betray my friend’s confidence. Yet I feel that we need to move the process forward. So I will share what I think is the minimal framework for success. It’s something that has evolved over the years. It’s best applied at the start of a product offshoring initiative, although it can also be used to devise a curative cycle. There are five dimensions to consider…
1. Work Partitioning. There are many ways to partition work in a distributed product team. It can be done on the basis of process steps, architecture boundaries or competency pools. Having explicit work partitioning is better than the ad-hoc approach. But the goal has to be to pick the best work partitioning approach on the basis of the product’s business success. Very few teams are able to do this. They get sidetracked into choosing the “easiest” option (i.e. most pain free for US/home team, or quick start for India team). This sows the seeds of failure or a middling success.
2. Roles and responsibilities. Alignment between responsibility, authority and accountability is the hallmark of any good organization. Getting this right is even more important in a distributed organization. But it’s not easy to do this right unless the work partitioning model is explicit and aligned with business objectives. Problems are easy to spot. If unaddressed, they will show up as complaints of micro-management by the India team. The US side often sees the same problem as a lack of accountability within the India team.
3. Team Experience profile. If the team is under-qualified, it will not deliver. If it’s over-qualified, people will be under-challenged and will leave (in a tight employment market). So getting the right profile of people (by roles) is critically important. In my view, this is the hardest success dimension to address for the leadership team in India. This is where capability building, career management, employer-of-choice branding programs become necessary. If these don’t exist, the solution space shrinks considerably.
4. Project management. There is the resource management school and the risk management school of project management. What’s relevant here is the risk management approach. Getting the two sides to engage in frequent ongoing conversations about future risks and their resolution is more important than just status tracking or change control. This means that a modified PMM model is needed on both sides.
5 Management styles of interface-pairs. Let me explain what this means. In a distributed product team, there are only a few interface-pairs – these are managers across locations – that need to collaborate closely to get the product out. They can be peers or in a reporting relationship. If these interface-pairs are able to work well with each other, then their organizations also work well with each other. In effect, they create the organizational climate for collaboration. There is a lot that goes on at the interface-pair boundary often filtered through the lens of cultural, geography, and economic differences. To make this work well, good situational leadership skills are essential. In my experience, this often requires coaching on both sides.
Mind you, these dimensions may appear simple but they are not. Their implementation requires a commitment to change on both sides. Building this commitment (around the success framework) is simple when there is only one product involved (say, in a startup doing product offshoring). It’s a more involved process, often requiring a workshop when a number of products are involved (as is the case in a large company setting).
In VERITAS we had carefully turned this framework into a self-assessment tool that was prescriptive about which dimensions to focus on without being directive about the specifics. The teams were encouraged to track their scores on a kiviat (radar) chart. Rather than compare teams with each other, the focus was to encourage them to improve their own scores over time. Seen in this way, the success framework as an antidote to muddling through.
Although, there was a high correlation between the scores and the perceived success of product offshoring, two caveats are in order. First, this minimal framework doesn’t address the dynamic associated with the rapidly evolving talent/employment market in India. For an employer to compete in this market, one has to go beyond this success formula. This is another topic by itself. Secondly, this framework is set in the context of a captive R&D offshoring center. Non-captives require a slightly different treatment.
If you have been part of R&D offshoring, please jump in (anonymously, if you like) and share your learning’s.
[Update: Also see the subsequent post: India R&D Footprint: Time to Evaluate and Fix the Portfolio]
8237 Responses to “A Practical Framework for Successful Product Offshoring”