Recently I talked with a developer who’s company hired an outsourcing provider that I had worked with. I knew about their collaboration, so I asked him how the software project was going.
He said, “Their code looks like they hire juniors and that their training program is W3Schools,” which translates to: he’s not happy with their level of work.
What was really curious about this encounter is that another client had great success with the same provider! In fact this client’s project managers were avidly moving projects there and developers who were working on projects with this firm raved about the talent level of the engineers and high quality of their work.
Two projects and two very different outcomes. Both our client and the developer’s company were working with the same provider in a similar staff-augmentation model. So what went wrong?
It is worth pointing out the obvious: a successful relationship between one client and a offshore software provider does not translate to a successful relationship with another client’s project.
Sourcing providers have their good clients and their not-so-good clients. The good ones are typically those whose managers work very closely with their team and the provider’s team to set the right patterns of activity and collaboration, to make the relationship work. This is what I refer to as “setting the course”.
Problems, such as those the developer I met was encountering, are often due to the failure of managers to take responsibility for and get involved with the initial setup of the teams: the establishment of the provider’s team, and the on going communication required on the client’s team to make the day-to-day collaboration work.
I don’t know what went wrong here but I would ask: Was the development manager or team lead involved in the provider’s interviewing of developers? Team selection is a critical factor and if you don’t hand pick your team you’re asking for trouble. Were specific technical criteria (such as level-of-experience in a technology set) given to the offshore provider? Were candidates’ skills tested by the internal manager or team lead before the project started?
The technical training and experience of a provider’s developers needs to be spelled out in writing and agreed upon well in advance. If the provider is not living up to that agreement, it’s time to work with the provider to make personnel changes. But too often, it’s a lack of client clarity from the outset that amplifies such problems.