Poor Results? 5 Major Concerns in Offshore Outsourcing

Agile Methodology, Customer Experience, Nearshore, Project Management, Successful Outsourcing

Do you have experience with outsourcing software development through an offshore vendor? What were some of the problems you faced? What problems did you recognize? What problems were glossed over in the final analysis that contributed to less than optimal results? What are your major concerns in offshore outsourcing?

It is no secret that offshore software development is a challenge beyond the usual issues in almost any IT project. Certainly there are successful projects – but what issues do businesses face when starting offshore development projects? Let’s break them down into five major areas:

1. Best Case Situations for Offshore Projects

Is your project a strong candidate for an outsourced, offshore engagement? Consider a few factors that can make or break the project from the start:

• Do you have good experience with the offshore outsourcing, the vendor, the size and type of project you are considering? Does your team? If the answer to any of these questions is not a clear, «Yes!» – you are facing an uphill battle.
• Is your internal goal for the project clear and well-understood across your organization? Is it well-accepted? In most cases, outsourced projects have several drivers, but they must be clear and rational in the current situation to be accepted. Common drivers for outsourcing are cost savings, access to resources and skills, and improved time-to-market because the project is expected to overcome some internal barriers to getting the project completed within constraints.
• Does your project fit well in situations where communication may be limited and operations (within the outsourced team) may be different than your own? In other words, can you describe your project in these terms?
  • Application requirements are straight-forward, well-described and STABLE (like a rock!). No changes are contemplated.
  • Application is not complex and technology required is not new or debatable. In total, the project is not groundbreaking
  • Functionality is documented and well-described in a user context.
  • Application is not large. It can be broken down into several, small, independent modules.
  • Project is not mission-critical or considered to be risky based on projected cost and time.

Of course, covering all these issues would make any outsourced project more successful, but it would also make them a bit of a unicorn in the world of IT. In the final analysis, very few (if any) projects have stable requirements throughout their development cycle. As functionality is developed, it is natural to look deeper and consider outcomes in a different light. But, if your project is one of those golden unicorns – then even your first offshore project has a decent chance of success. If your project doesn’t fit into a best case scenario for offshore, you need to be aware that mitigations for shortcomings have costs and may drive you into corners that are difficult to escape.

2. Failure to Disconnect People and Problems

This issue is a problem across outsourcing but of particular importance in offshore relationships. When problems are perceived during a project, they are most often traced back to an individual or team, not the processes or operational procedures in place that created the environment where the problem happened. Instead of examining the situation, organizational norms, processes and methods (and their implementations), we have a strong tendency to look for a scapegoat, a person that is at fault. This leads to a loss of trust within the team as a whole and enforcement of hierarchical control – exactly the opposite of what we need if we depend on a strong, agile team to function properly. Increased hierarchy means less direct communication with developers and conversely, less independent thought from people whose skills as «knowledge workers» makes them valuable. In an offshore situation, this can be fatal to project outcomes if there is not full-time, offshore and onshore coordination and management – which of course – raises costs and lowers productivity. And because once we have targeted an individual rather than other factors, we are very likely find ourselves repeating the same problems over and over, in slightly different configurations.

3. Travel & Communications

Of course, the reason that travel and communication issues are strongly linked is that – in outsourcing you travel to facilitate better communication. Regardless of all the advances of technology, face-to-face communication is still the richest, most efficient form of communication in the design, development and production of custom software. If you want to achieve trust, a shared understanding of a product, a clear picture of your entire team (outsourced and inhouse as one), there is no better way to do it than getting everyone together in one place. Barring that – you can also achieve a lot by getting key resources together to kick off a project but there is still a deficit in communication across the team that only direct contact can overcome quickly. In addition, the experience of direct contact also holds longer within the team – enabling true collaboration across the project lifecycle.

But if hourly labor costs are considered to be part of the project drivers, the reality is that the best prices for labor on an hourly basis are likely to be in fairly distant, even remote locations. This means that travel by key personnel to or from the outsourced vendor home area is likely to occur over a longer period and many «hops.» Although the key outsourcing centers in India are not remote by today’s standards of global business, they are a considerable commitment in time and cost. You might think you can get by with inexpensive flights, accommodations and simple food – but after several days of low budget travel you are likely to find you are not at your peak in critical business meetings. The same will be true for teams coming to you from a distant location. In that case, it is more than a few amenities that can get in the way. Visas, entry processes, unfamiliarity with local customs and expectations can all become barriers to having a productive few days after a long trip.

In projects with some uncertainty, this issue of time and cost can delay travel that would be beneficial to communication until a situation becomes critical. Travel avoidance creates situations where meetings that should be cordial, collaborative discussions become frustrating negotiations that are more likely to be «lose-lose» than «win-win.»

But let’s say your project is fairly straight-forward and although there is some uncertainty, you have enough cash to allow for more than one trip with your key resources at a minimum. What other areas in communication do you have to consider in offshore situations?

• Language – Although English is certainly the language of business around the world, it isn’t everyone’s native language and although many people can read English, not everyone can write and discuss ideas verbally with the same proficiency. In addition, culture and local contexts are part of understanding each other, no matter what language is spoken. A common spoken word in one location may have no direct counterpart in another location. My «door jamb» is funny if you understand what you hear as «jam» only makes sense as a form of marmalade. If a member of your team has very little conversational experience in English, it is likely they just won’t speak in meetings because they are afraid they might say the wrong thing and they can’t follow the conversation completely. As these barriers rise, so do the work-arounds. A facilitator or go-between is added to «ensure clear communication» but in the process of clarifying they also over-simplify and leave out critical details. A translation point is added so each side doesn’t have to deal with complex issues in a language they are not familiar with but because the translator isn’t a technical or business expert, many nuances are lost in translation.

• Time Differences – In offshore situations, the working day time difference between teams can mean that there is no overlap or that there is only one or two hours in a day when some direct contact can be made. Even when accommodations are made, it is generally done by putting one or two people in the combined team at a disadvantage. If the product owner makes themselves the key point of contact, they will have to find time to accommodate the outsourced team and their local team members which can result in some very odd and frustrating hours. If a local technical manager and a distant technical manager are implemented (as is often the case), communication fidelity is lost because the production team and the product owner are not in direct communication most of the time. There are many variations of workarounds for time differences, but for software development projects, this can be a very significant issue and barrier to good project communication.
• Us Versus Them – In any situation with two teams in different locations, there is always a barrier to getting the team to think as one unit with shared goals and responsibilities. In offshore situations, the teams face significant barriers of culture, language, vendor-to-client relationships, and time differences together. If things go wrong at some point, the tendency to blame and in many cultures, accept blame without question, can deepen the divide between teams. Trust, the ability to speak openly and discuss issues without fear is a serious problem in offshore teams on projects with shifting requirements and critical outcomes.
• Business Domain Sharing – Every successful business has internal, proprietary knowledge is part of their key business advantage. Sharing that knowledge openly; answering questions with proper context and depth takes time, though, and trust. In outsourcing, particularly in offshore situations, sharing proprietary knowledge can be very difficult. Legal concerns, technical business language, access to subject matter experts (SMEs) in real time, and the dense, technical documentation that is often generated to overcome issues can become barriers to productivity instead of bridges to understanding. Few teams understand at the outset how difficult business domain sharing can be and how important it is to developing a critical application that fits a business model well.
• Frustration Overhead – All these points add up to a level of frustration on the project team that makes it very hard to work together and deal with ordinary project issues. The development team becomes frustrated when they can’t clarify requirements with the product owner or SMEs in a timely fashion. The product owner becomes frustrated when (because requirements couldn’t be clarified in a timely fashion) functionality is developed that isn’t what they wanted. The internal QA becomes frustrated when code and UI quality doesn’t meet their standards for maintainable code and usability. When communication is limited to a few issues at that are considered to be critical in the moment, these frustrations build and create deep divides and barriers. It is rarely discussed, but the mental load of built-up frustrations is a big contributor to low productivity and project failure.

4. Technology & Methodology Differences

Globally it may seem that people in technology are all in sync – but that is a big assumption. Regionally, the access to new technology may be limited by licensing, educational resources, access to technical information, experience and local preference. The gaps in methodologies can be even greater. An offshore team is limited in their implementation of agile by the circumstances of their location in relation to their clients. Real-time communication and collaboration, the cornerstone of agile, is at a premium if it exists at all. DevOps practices and experience may not exist in the their context.

In these situations, offshore teams have to deal with several issues that can be critical factors in project success:

• Are the development platforms and systems the offshore team is experienced with appropriate for productivity and the target application? Will there need to be training and alignment to reach a solid, common platform?
• Are their operational practices compatible and up to standards? Is their implementation stable and dependable?
• Is their implementation of agile fully functional or so limited by communication delays and cultural differences that it is barely recognizable?
• How is their QA done? Is it tightly integrated into development practices and responsibility or completely separate and walled in? Will it integrate seamlessly with your functional QA or will quality and communication issues create endless loops and finger-pointing?
• Is their coding productive, up to standards and maintainable? How much time and oversight on coding issues can you have in an offshore situation where the team is operationally separated by many hours? Is their team biased to keep hourly costs low (more junior resources with low experience versus senior resources)? Do they practice mentoring, code review, and have a learning atmosphere (versus blaming)? These things are hard to know if you cannot interact with individual members of the development team regularly without barriers.
• Do they have small, skilled teams or large teams with lots of communication overhead? Is their turnover high or low and stable? In many emerging economies, turnover on technical teams can be very high because of competition for good-paying jobs and resources.

These issues can be dealt with by experienced, motivated offshore service vendors, but understanding the issues they are dealing with is very important.

5. Social and Organizational Differences

In many ways, the social and organizational issues in offshoring are similar to the other areas we have mentioned. Organizations in the US tend to be flat (or at least flatter) than their offshore partners. Hierarchical cultures and organizations don’t foster the independent thought, responsibility and soft skills that form the backbone of the agile software development methodologies in wide use today. That doesn’t mean offshore resources can’t function fully as agile teams, but it does infer there are problems to be considered and dealt with to be successful.

Might seem risky but is it really? Depends on many factors.

All outsourced teams have a certain amount of risk adversity. It is much easier to go with the easy choice rather than consider something new that the team may be less experienced with even though it may have great benefits. This is even more true when the team is separated from their client team by communication barriers. Offshore teams face a double burden of hierarchical culture and low communications efficiency. They may be very adverse to suggesting alternative approaches because if there is any risk, they feel they are taking on themselves rather than operating as a trusted part of the whole project team. The issues of risk adversity also trackback to general business practices in other cultures. Client – vendor relationships can be very different outside of the US.

And finally, along with a high turnover rate in a competitive atmosphere for skilled resources, there is a tendency in software development teams to feel a lack of challenge and access to new technologies. This is especially true in emerging economies where the access to advanced technology and challenging assignments may only come from companies providing outsourcing to US and European companies. What from a distance may appear to be a stable job in a long term project on a big team becomes a career killer in an emerging economy. Keeping a sense of ownership, shared opportunity and trust is more challenging when your offshore team doesn’t understand or share a level of personal context with you.

Forget all your concerns in Offshore Outsourcing. What is the Alternative?

Ok – but really, even with a high level of project failure for offshore software development projects, there are many successful outsourcing engagements – or no one would ever do it. Experience does count and knowledge of the bumps in the road is very helpful. Keeping projects relatively small and low risk is of course a simple alternative, but it is not efficient in the long run if you actually have big goals.

I wouldn’t be honest if I didn’t admit a bit of bias here. Scio is a nearshore vendor for outsourced software development to our clients in North America from our development center in Mexico. That means that although we are subject to all of the normal issues in the field of outsourcing, our practices and focus give us an advantage when it comes to communication and a lot of the factors we have mentioned in this article. We can work in real time with our clients. We have at least a six hour working day overlap with our client teams and most of the time, we have seven to eight hours when we are available to work and communicate directly across our project teams. We share most the concerns and elements of North American identity and culture. We are fully aware of and have worked with US teams, indirect communication and collaboration with them as individuals. We have access to the same infrastructure, technology, standards and processes. We can collaborate in conversational English without barriers. After all, we neighbors – sharing many aspects of North American life transparently. Travel to our clients in the US or from our clients to us is not much different than travel across the US. Visa access for business is part of the NAFTA trade agreement.

If you are looking for an unfair advantage at the level of hourly wage, our costs are not as low as those in emerging Asian economies, but when it comes to Total Cost of Engagement (TCE) our costs fall into line but with less risk and complication. Nearshore is not a silver bullet – but if you are facing issues when it comes to resourcing a team and you can’t deal with the risk that comes with offshore in projects that could have unstable requirements – an experienced agile team that can work with you as a partner in real-time, in direct collaboration with your team, can be a serious advantage.

Do you need an outsourcing partner? We want to help you

Are you interested in a serious advantage in your next software development project? Scio is a nearshore vendor of outsourced services for software development to our client base in North America. We understand the needs and issues our clients face and actively partner with them to find solutions and make their projects successful. If you would like to know more about what we could do for you – contact us.