I strongly believe that, nowadays, the most important skill required from a software R&D outsourcing service provider is not domain or technology expertise but communications proficiency. My opinion is based on personal, corporate, and industry-wide experience. Auriga has a long record of positive feedback as an outsourcing company. For example, more than once, we received 100% satisfaction ratings from large multi-national clients; two years ago, we were named the number-one engineering services provider worldwide; and just a few weeks ago, we were included in the top three (~1%) service providers of one client organization. Of course, as any sane company does, we analyzed the reasons why we succeed (and why we fail when it happens, fortunately less frequently). What we discovered is that the main reason is precisely the subject of this article: well-tuned communications and cultural proximity with our clients.
It’s also easy for me to accept the relatively low importance of narrow technical skills compared to communications based on my personal experience. I started in the 1990s as a software engineer, and since then, I have participated in various projects from developing a full-text database search engine using Delphi to writing complex system-level software for such different operating systems as Linux, Windows, LynxOS, and VxWorks to creating traditional Windows GUI applications. I spent more than fifteen years at Auriga watching the careers of other engineers, and I can tell that I’m far from being unique—almost every seasoned software engineer can tell a similar tale of changing operating systems, frameworks, programming languages, etc. on his professional path.
One story comes to mind. At some point, one Auriga team faced a situation when they had a rather complex system that extended the PCI enumeration process and dealt with device resource assignments, memory mapping optimization, network virtual device drivers, and other low-level issues implemented for Linux. And they had to port it to Windows without having any prior experience with Windows internals, bus and network drivers, physical device objects, and other internal stuff required to implement that complex solution properly. Well, they just did some studying and some research, and in six months, the project was completed. Later, the team successfully ported the product to VxWorks and a couple of other operating systems, also within very tight timeframes. Learning a new framework is relatively easy if you know what you are doing. I know, well, because years ago, I was a part of that team.
With this experience under my belt, nobody can convince me now that merely specializing in some domain for years allows you to perform really complex projects in the area successfully. Overall experience as an engineer does count, but switching from language to language, OS to OS, vertical domain to vertical domain, methodology to methodology is relatively quick, straightforward, and even useful for bringing good techniques from context to context.
Thus, unless you only need to do a short-term project (with no support for the result required from the provider after it’s delivered), technological and vertical skills in your narrow segment are not what you should be looking for when picking the most suitable outsourcing software provider. Allowing your provider the time to gain all the necessary knowledge and practice in the new area only leads to a short delay at the very beginning of a project. The ability to understand what you need, find and communicate the best path between implementing all ideas as they were expressed and doing it on time and in budget, work together with other teams to integrate with other projects—these are the issues that are more important to the success of the usual software product/solution development lifecycle.
That’s one of the main reasons why “agile” became a buzzword several years ago. And that’s the reason communications are extremely important to the success of an outsourcing initiative. If your project cannot be completely done in one to two months, you can’t describe everything up front and then go and implement it. It’s not only that it is impractical to write everything down and try to predict which details will be important for implementation. Requirements change. You should accept it as a necessary evil: You will always have changes to your original plans. Some features take more or less time to implement, you may gain a new key customer with specific requirements, your marketing can gather feedback for the first version from users that blow up your insights on it, you can decide to showcase your product at an industry event soon, a new product to integrate or compete with appears, or your budgets are cut or increased based on last year’s results. There are many reasons and one consequence: You will have plenty of changes to your requirements, priorities, and plans.
Besides, you just need that feedback from the implementation team. You need somebody to tell you, “Hey, if you simplify that requirement just a little bit, you can reduce the implementation time from three months to three weeks.” And in many cases, when you outsource, you already have your own in-house development team and/or a set of other outsourcing providers in place. They develop other products/solutions, implement common components to reuse, and define common style guides and UI elements. Using each other’s work and API also requires good communications. Things become even more interesting if you outsource the maintenance of software that you previously developed in-house. Most often, the knowledge about the architecture, behavior, and reasoning behind certain design decisions is at least partly in the heads of the development team, not on paper. That means the outsourcing provider’s team needs to pull that knowledge from real people to be successful.
You don’t have to trust only our experience. If you read research studies on outsourcing success factors on the Internet, they also list communications as one of the top factors, often the number-one factor. Here are just a couple of examples:
- Communications were listed as the number-one critical factor in managing software outsourcing relationships according to a study of leading Indian providers. It was mentioned as a critical factor by over 95% of studied vendors and over 80% of their clients.
- Communications between client and service provider managers and communications between client and service provider personnel were listed as the top two success factors in the 2006 Outsourcing Survey by Enterprise Systems journal.
In a nutshell, if you are looking for an outsourcing provider, pay most of your attention to the communication capabilities of the companies—that’s even more important than technical competence. Of course, there are many details behind that simple statement. I hope I’ll have time to touch on at least some of them in future posts.
