by Scio Team | Jul 23, 2019 | Agile Methodology, Customer Experience, Nearshore, Product Development, Project Management, Successful Outsourcing
Work is always measured in some way. If you are doing repetitive work, the tendency is to measure the number of repetitions, like the pounds of fruit picked by a field worker in an hour or a day. If you are doing knowledge work, the tendency is to simply measure hours of work spent on the problem, assuming that a) the person doing the work has the necessary set of skills and a comprehensive knowledge base of the subject at hand and b) they spent enough time to evaluate the problem sufficiently and provide a balanced solution. If you are doing time and/or payment-dependent contract work, the main consideration is did you complete the work assigned in the contracted period and at the specified cost?
This all seems relatively benign and normal in the world of work because it assigns a value to work that can then be measured and evaluated in various ways. Did you pick more fruit this week than last? Did you solve more problems in this quarter? Did you complete all your contracted work on time and budget?
Software development is, of course, one of the most valuable types of knowledge work being done globally today. Since development is usually the domain of teams and is at this time, largely done with some form of agile and/or lean methodologies, the measurements tend to be a combination of individual and team metrics applied by various means. Some common metrics are:
When we get beyond these three common methods and their minor variations, we start getting into more complex models (!!) that tie team performance, quality, project length, man-hours, adherence to production and methodology standards and complex team models in DevOps implementations.
We Have Questions
At the end of the exercise, however, it is done, we end up with some sort of measurement of the work of software development. But as we do, we need to ask ourselves a few important questions:
What does our measurement tell us? What is it not telling us? If we are measuring lines of code or functions, is the measurement telling us if the work was efficient or just an output meant to produce more (or a given number of) lines/functions over a given period? Were the lines of code or functions really efficient and useful? Programming is very comparable to writing. Some writers are more efficient at expressing thought and others see a more elegant way to express a thought without addressing it directly. Some programmers are more efficient because they reuse code multiple times throughout the source with efficient use of variables. Some functions in a program are critical and getting them right is tough, requiring time and effort. Other functions are simply “eye-wash” and don’t have a real bottom-line value. There as many ways to game the system as there are ways to produce better code with fewer lines. Every programmer, every team, and every project has different dynamics depending on the language being used, the type of environment, the technical problem being dealt with and many other factors. If you use a pure “number of X metric,” you have to be clear about what it means and doesn’t address.- Is our measurement comparable? Can it be used over the long term or compared across projects or teams? Frequently, this is where the complex math becomes part of the equation and frankly, begins to fail to do its job effectively. The more we try to “normalize” measurements across a single project, between teams, and across projects and teams, the more subjective the outcome becomes. Were the technical hurdles encountered at the beginning of Project A really comparable to Project B? If we decide there is a significant difference, how do we adjust for it? Did Team A experience more changes in team composition than Team B? How do we account for that issue? Are we comparing skill levels, experience, time to reach “normal productivity” or some other factor? Was Team A really suited to provide the skills and experience needed for the given project? Did their productivity fail to reach the levels expected because of issues outside of their control? In most cases, the more you try to normalize between measures of productivity between individuals, teams, and projects, the less sure you can be you have a reasonable common measure. And in the end, the question becomes, is a comparable metric what we really need?
Isn’t any measurement better than no measurement? Can we afford to fly blind? Certainly, if you have an outsourced team, multiple teams, and/or multiple projects you have to begin to understand why some projects seem to work well and some don’t. You need to be able to judge if a project is going off the tracks so you can get it back in line before the problem becomes critical. Finding ways to measure performance and productivity would seem to be the best tool to address the common issues in software development projects. But if the measurements we are using aren’t really addressing the problems we have, how are they helping us? Are they really more than just busy work for managers and bean counters?
The more we look at the problem, the more we begin to understand that measurement for the sake of monitoring “something” isn’t really useful. But on the other hand, measuring any aspect of software development is better than monitoring nothing at all and simply hoping everything will work out in the end. Even a weak measurement provides some level of confidence if it is used consistently and we understand its shortcomings well enough.
In agile teams, there is another, more important way to look at things. If we give the team simple methods they agree on and understand, like story points and burn down charts, they will know when they are performing well and when they are pushing too large a boulder up a hill. Inside the team, they know who is consistently performing and producing efficient code with fewer problems. The team knows when its backlog is too great to finish in the allotted time. Team members learn quickly who can be asked for pointers on how to approach a problem properly and who cannot be depended on reliably. We can stand around, pointing out issues with the common ways to measure agile team performance, but their value is those common agile methods are basically useful to the team to understand where they stand in relation to the work ahead of them and their quality performance. Where we get into trouble is when we try to extract the common measures and try to draw larger conclusions from them.
The Reality is – Communication is the Key
If we get past trying to use performance metrics outside of a single project and narrow our focus to what they do for a team inside of a project, we begin to see their value more clearly. The team knows what is going on. They may attempt to fool themselves or others, but in the end, they can see the light in the tunnel and they know if it is a successful end to the project or an approaching train. The problem is to get them to trust each other and the larger team enough to surface the problems they see as soon as they see them, without fear.
The level of trust and responsibility required for open communication and collaboration is perhaps the largest problem faced in software development projects. It is the “why” behind the invention and popularity of the agile and lean methodologies in wide use today. Conversely, the larger the organization, the more critical and costly the project is to the organization, the less likely it is that the team will feel and be enabled to inquire and speak out about the problems they believe they are facing. In a large organization, metrics are the shorthand to avoid having “high touch” with every team and individual. In a costly, critical project, metrics are meant to be the “truth-tellers” to assure stakeholders that things are well controlled, even though everyone knows that metrics can be gamed without much problem. And the more the metrics are relied on, instead of the knowledge inside of the team, the more likely it is the project will get out of hand before the problems are addressed.
Responsibility. Trust. Communication.
So what is the bottom line on measuring performance and productivity in software development projects?
- Measurement is most useful inside the software development team itself,
Planning Poker
where the knowledge resides about what is really going on from day today. Everywhere else, it is just as likely to be smoke and mirrors as it is, to be honest, and useful – depending on who is using the metrics and for what purpose. If the team doesn’t understand the metrics applied and can’t use them to better understand where they are in relation to the work to be done, their quality performance and general efficiency as a team, the metrics will fail to give back their primary value – keeping the team and project on track.
-
The agile methodology relies on individual and team responsibility, trust and communication. If these three points cannot be achieved within a team, agile and scrum are just a bunch of processes and procedures that may or may not be helpful in organizing work. If the team is just “going through the motions” in taking responsibility for tasks, assessing and managing their backlog, and participating in standups and retrospectives, additional metrics and measurement will not provide much value. They will provide information to a larger audience too late to enable outside forces to do more than triage injuries to the project.
- Working through what may appear to be problems or what may seem to be a simple solution requires peer-level coaching and communication, not blame. If we understand that the team itself really knows what is going on – getting them to assess the problem honestly and figure out how to address it requires something other than pointing fingers, avoiding issues and top-down communication. It also means that the team needs to take responsibility, as soon as anyone recognizes a problem could be on the horizon, to consider it seriously and determine both the size of the problem and solutions that could be used to address it. And so what if the team raises an issue that may turn out to be nothing of great importance? We’ve been called to action to look at it and we will all come out of the conversation wiser. If everyone in the conversation addresses each other as a peer, rather than hierarchically, there is a good reason to think that the next time a problem is encountered or perceived, it will be openly addressed, rather than swept under the rug.
Three points to consider and use in conjunction with standard agile and scrum-based tools. You can use more and you can draw all sorts of conclusions from the systems you bring together. But in the end, if they don’t bring immediate value back to a current project, what value are they really serving?
Looking for a development team? Contact us we can help you!
Scio provides nearshore software development services for our client base in North America. We work closely with our clients to ensure that the projects we are involved in have the level of communication and understanding needed to reach successful outcomes. If you have a project where you think we could help, please contact us. We would be happy to discuss your needs.
by Scio Team | Jul 9, 2019 | 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.
by Scio Team | May 7, 2019 | Customer Experience, Outsourced Engineering Team, Successful Outsourcing
No matter who you are and what culture you were raised in, hearing the word “no” can be downright devastating. After all, the word is commonly associated with utter failure and defeat. There are various reasons why people say ”no” to you. However, your words and actions after the rejection can make a world of difference, especially in the business field.
What “no” really means
Most entrepreneurs dread getting a negative answer. It does not matter whether the rejection comes from a supplier, business partner, or client.
Just imagine: if saying or hearing the word “no” can cause great conflicts within a workplace, how much more damage can it do when it is used in a business deal between different cultures? People who don’t share the same language, social, and economic backgrounds are sometimes bound to misunderstand each other.
However, “no” can mean differently in each culture. While it can initially be perceived as a negative response, it may also just be an opening for a new idea or starting point. In this case, cultural competence becomes the key to handling “no,” regardless of where it comes from.
How different cultures handle rejection
Modern technological advancements have made it possible for entrepreneurs to reach potential clients and business partners across the globe. Indeed, it is very rare to find a workplace that is not highly diversified as a result of this globalization.
However, this cultural diversity in a workplace can be a source of conflict among the employees and the managers. This is especially true if there is persistent resistance to accommodate certain values and beliefs of other cultures.
Nevertheless, being aware of the different cultures is not enough to thrive in the world of business. It is also essential to understand where each culture is coming from. Here are some of the most common cultures that you might see in the workplace.
Americans
Americans tend to be straightforward and speak their minds directly. They prefer the discussions to be straight to the point. They also prefer to speak directly to all parties involved rather than ask a third party to send the message for them.
For this reason, whenever an American hears the word “no,” he or she is keen to hear the exact reasons for the rejection. For them, it is quite usual to dish out and hears both positive and negative feedback since these appeals to their high sense of individualism. This is not to say that Americans are not afraid of confrontations. They just tend to be more vocal about their thoughts and feelings.
Indians
With approximately 4.8 million people in the workforce, India holds the second largest number of workers in the world, there is a big chance that you will meet more than one Indian colleague in the workplace.
Since India is composed of different cultures, languages, and religions, it can be difficult to find the right approach in business dealings. For the most part, having a flexible approach works when interacting with an Indian colleague in the workplace.
However, Indians place a high value on respecting authority figures in the office. For example, it is considered rude to greet a younger colleague first before a senior one. It is also essential to appropriately address people by their respective titles (e.g., Doctor, Professor, etc.)
Like workers from other Asian countries, Indians avoid getting into verbal confrontations with their colleagues. As a result, the way they communicate can be frustrating, especially when they are conversing with a person from a different culture (i.e., Americans). Indians prefer indirect or circular communication. More than verbal, there is a need to watch out for gestures, facial expressions, and other cues to understand what they truly mean.
For them, the phrases “I understand,” “Maybe we can try that,” or “Yes, but…” may not exactly mean that they are agreeing with your idea or suggestion. However, directly disagreeing or saying “no” can be perceived as downright impolite or shameful. Thus, when they are in the receiving end of a direct rejection, they tend to take offense and get more critical about themselves.
Mexicans
In terms of cultural competence, Mexicans are right on top of the food chain. Due to their large numbers and relatively young age (compared to other employees in an ordinary American company), they are more accepting of any cultural shift in the workplace.
Thus, the way they handle rejections can be considered as a curious mix between the American and the Asian approaches. While they are not shy in accepting both positive and negative feedback, they are wary of public confrontations.
Hence, unlike their American counterparts who have no problem airing their grievances in an open forum, Mexicans might take offense if you reject them openly in front of their co-workers. In this case, the best way to give a rejection or constructive criticism to a Mexican employee is to isolate them from the pack and talk to them privately.
Get Scio
Any business person should know that hearing the word “no” is not the endgame as each culture takes rejection differently. Our technical and industry expertise is only compounded by our highly skilled, dynamic, and diverse culture that understands how to handle and work around that initial “no” from a client. Need to develop products that would get instant approval from clients around the globe? Contact us, and get to know some of the Top Houston Software Developers
by Scio Team | Sep 18, 2018 | Agile Methodology, Customer Experience, Nearshore, Project Management, Successful Outsourcing
First, let me say this is not an article for budding sociologists or business leaders who think that the last 20 years of increased person-to-person connectivity across the world, with the Internet, social media, entertainment and globalization, have broken down the differences in cultures across the world. The world has changed to be sure, but not on the scale you might imagine. People across the world still see things differently and interact based on their point of view, and that is as true in business as it is in international politics.
Culture actually takes a long time to change, whether we are considering an established business or even more so, a country or region. Studies have shown that the recent growth in communications across the world has only added to the social stereotypes we have to cut through to understand individuals from other cultures. And this is not to say that everyone within a culture will have the same values and drivers. While sociological texts provide many comparisons between cultures, they are at best, a general understanding of the expectations of people inside a society and how they interact with each other.
But at a business level, for a company wanting to outsource software development, what does this really mean? Why should you care? Software development is just a form of work and technology is pretty ubiquitous in the modern world. If people have the skills and experience to do the work wherever they are located, do their cultural values matter?
To investigate this question, let’s imagine a scenario that we (as an nearshore outsourcing vendor in Mexico, serving clients in North America) can relate to. You are starting a project with an agile software development team located in the central area of Mexico. Your team is located in the US Plains region. You might assume that because Mexico is just south of the border – they would know a lot about your culture – and you would be right. People in Mexico and the US consume a very similar range of entertainment and consumer goods and they cross borders in both directions for vacations and visiting their families. But does that fill in the gaps in understanding generated by sensational news reports and differing political agendas on each side?
Sadly, no. Although people in the US visit Mexico in increasing numbers every year, their destinations tend to be resort enclaves like Cancun. Unfortunately, those locations have more in common with the US than Mexico – with good reason. They are intended to make a US and international traveling public comfortable during their stay in another country, not confront them with challenges of language or culture.
On the other side of the coin, people in Mexico generally have relatives in the US and many have visited at different times, outside of the vacation areas like Disneyland. They have a good general understanding of US society, but in most cases, from an outsider’s point of view, even if they have been a resident of the US for an extended period of time. So, while people in Mexico have a fairly good understanding of US social interactions, it may not translate to an easy transition to a working team without some additional understanding and work on both sides.
To understand the differences between the two cultures, take a look at a comparison between the US and Mexico as outlined by studies done by the Hofstede Center.
Hofstede measures cultures based on six areas (adapted from the descriptions provided by the center) :
- Power Distance – The degree to which the less powerful members of a society accept and expect that power is distributed unequally. The fundamental issue here is how society handles inequalities among people. People in societies exhibiting a large degree of Power Distance accept a hierarchical order in which everybody has a place and which needs no further justification. In societies with low Power Distance, people strive to equalize the distribution of power and demand justification for inequalities of power.
- Individualism – The high side can be defined as a preference for a loosely-knit social framework in which individuals are expected to take care of only themselves and their immediate families. Its opposite, collectivism, represents a preference for a tightly-knit framework in society in which individuals can expect their relatives or members of a particular in-group to look after them in exchange for unquestioning loyalty. A society’s position on this dimension is reflected in whether people’s self-image is defined in terms of “I” or “we.”
- Masculinity – The high side represents a preference in society for achievement, heroism, assertiveness and material rewards for success. Society at large is more competitive. Its opposite, femininity, stands for a preference for cooperation, modesty, caring for the weak and quality of life. Society at large is more consensus-oriented. In the business context, Masculinity versus Femininity is sometimes also related to as “tough versus tender” cultures.
- Uncertainty Avoidance – Expresses the degree to which the members of a society feel uncomfortable with uncertainty and ambiguity. The fundamental issue here is how a society deals with the fact that the future can never be known: should we try to control the future or just let it happen? Countries exhibiting strong UAI maintain rigid codes of belief and behaviour and are intolerant of unorthodox behaviour and ideas. Weak UAI societies maintain a more relaxed attitude in which practice counts more than principles.
- Long Term Orientation – Every society has to maintain some links with its own past while dealing with the challenges of the present and the future. Societies prioritize these two existential goals differently. Societies who score low on this dimension, for example, prefer to maintain time-honoured traditions and norms while viewing societal change with suspicion. Those with a culture which scores high, on the other hand, take a more pragmatic approach: they encourage thrift and efforts in modern education as a way to prepare for the future.
- Indulgence – On the high side, societies allow relatively free gratification of basic and natural human drives related to enjoying life and having fun. Restraint stands for a society that suppresses gratification of needs and regulates it by means of strict social norms.
From the comparisons generated by the surveys behind the studies, You can begin to see some basic differences between the expectations of people in the US versus Mexico:
- People in the US are generally less accepting of inequality in their interactions than people in Mexico. Business and organizations in Mexico tend to be more hierarchical and less accepting of “flat” organizational structures.
- In line with their lower acceptance of inequality, people in the US have a higher level of individuality. In Mexico, although this dimension is changing rapidly and different among segments of the population, individuality is less evident.
- In areas of masculinity versus femininity, the two countries are very similar, but Mexico is slightly higher. This shows in a what to outsiders may find to be a surprising amount of competitiveness between individuals and in business within Mexico.
- Mexicans have a high propensity for avoiding uncertainty in comparison to people in the US. This plays out in less propensity for risk and higher reliance on pragmatic solutions.
- People in the US and Mexico have very little difference in their orientation to long-term versus short-term goals. Both societies generally favor conservative goals.
- In contrast to the difference between the two societies’ individualism, Mexico is much higher on the scale of indulgence than the US.
Understanding these basic differences however, doesn’t tell you a lot about how a team of individuals might deal with a business situation. If you imagine a situation when the Mexican team is faced with working over the Christmas holidays to meet a deadline – you might expect some strong push-back because of long-term family traditions and expectations. But you could also expect that in the end, the team would go along with the need because of the value of having work and stability over the long term. But, if you didn’t understand underlying cultural expectations, could you also provide enough incentive to ensure production would not suffer during the period? You could generally expect that some special indulgences for the team would help, but what would really drive them?
Dealing with a specific problem requires more than a general understanding of a team’s cultural distance from your society. There are many layers of the cultural onion, including at a minimum societal, business, and individual levels, that impact the way a team interacts. Almost no one in business today has the time or resources to do the work required to really do a “deep dive” into comparative cultures to find a perfect match for their project. It is important to know we have cultural differences between us when we start a project, but from a pragmatic point of view, it is more important to know how to bridge them than to find “someone just right.”
Bridging the cultural divides goes back to best practices in starting all outsourced projects with remote teams – the initial period of team formation and alignment. Getting teams together, face-to-face, is critical to breaking down barriers and creating an atmosphere where cultural understanding can grow. You can’t expect either side of a team to change their own cultural profile, but you can put them in situations where their awareness of cultural norms within the team is improved and their ability to work together improves. Direct communication and interaction, in both work and casual situations, opens up opportunities to remove stereotypes and replace them with real, dimensional understandings of individuals.
In the end, the simple fact is that there are cultural differences between teams, even in the same company and in the same region. The cultural studies available should simply reinforce that understanding and the importance of dealing with them, not drive you away from using outside teams. You cannot use studies that give you only a general understanding of society to understand a specific team, although they may help you understand where to start.
From that point of view, if you are interested in finding an outsourced team, vendors that understand cultural dimensions and have ways to deal with them from the outset are going to be your best bet. Particularly in agile or DevOps implementations, trust and understanding are among the most important parts of team formation. Scio provides outsourced development teams to our nearshore clients in North America, with the elements necessary to ensure success, including team building approaches to fit your specific situation and assignment. Our teams have less geographical distance and more working-hour overlap than offshore providers which lowers the issues that new teams have to deal with at the outset. We would be glad to discuss your next project and how we can help.
Now we would be happy if you could help us share this page on your social networks so that we can reach more people who need help in these areas or are looking for a software development partner. All you need to do is click on one of the buttons below. Thank you very much!
by Scio Team | Apr 25, 2016 | Agile Methodology, Customer Experience, Nearshore, Product Development, Project Management, Successful Outsourcing
Outsourcing is a standard practice in the software development industry and it continues to experience steady growth, year after year. Among the common drivers cited are lowering costs of outsourcing, rapid acquisition of skilled resources, and avoiding staff overhead for one-time projects that would result in layoffs after completion.
In other words – it is all about costs in one way or another, whether they are real expenses or lost opportunities because you could not bring together a new team for a project in time to achieve your market. But, when you have paid the invoices and implemented your new application, what is on your balance sheet? Did you really save the money you thought you would? Are there hidden costs that have drained all the benefits out of the engagement?
10 hidden costs of outsourcing you may not be considering (in no particular order):
#1 – Deciding that driving cost to the lowest level possible is your primary goal
Are you confused? If outsourcing is all about costs, how can it be that using lower costs as your primary reason for outsourcing would actually end up costing you more?
- The lowest cost vendor cannot also be the best equipped with the best resources, deep expertise, strong cultural fit, high reliability and excellent real-time communications in your language. Solving each of the issues mentioned has a cost to the vendor, during the contract period or before to find, train, and maintain the necessary resources. Pushing to the lowest possible costs will require trade-offs that you and your team will bear. You may be able to anticipate the cost of working with less experienced and less independent resources at a production level, but can you also judge the costs that could come when unexpected issues arise? Have you ever experienced a project without unexpected issues? Really?
- Often, when price is the primary driver, the service buyer decides to manage costs by requiring a fixed-price bid. The upside is the risk is placed on the outsourcing vendor. To mitigate their risks, the vendor will then require extensive documentation, a detailed waterfall-type project plan that leaves acceptance testing to the end of the project, and penalties or prolonged negotiation if changes are needed. Plus, to pad for risk, the vendor will actually increase their bid because they know that fixed-price engagements rarely finish on time and within budget. In addition, they may decide to use less experienced resources (lower cost) overseen by senior resources (high cost, but with little time to look deeply into design and coding issues), So, in the end, instead of gaining assurance the project will end on time with an expected cost, the buyer has more cost for upfront specifications, more risk the final application will meet specifications as written but fail to achieve its goals, and much less oversight and flexibility once the project begins. The vendor will manage to the contract requirements and not the business goals their client decided were important internally. The vendor takes the entire responsibility for cost control, quality assurance, and management. In most cases, this means if their timeline or costs get out of line, quality control and communication between the development team and the client team will suffer.
- If your primary driver is cost, you will probably be pushed to offshore resources that are very low cost but have difficulty making their teams available in real time to collaborate with your team, lack good communication skills in your language and little in common with your culture. In these cases, you will have to do what you can to mitigate the fact that 28% of projects fail because of communication issues and 16% fail because of poor cultural matches.
#2 – The cost of selecting a vendor
Few buyers have a budget for selecting an outsourcing vendor and if they do, they rarely allow for the work that would really contribute to successful projects and relationships.
- Up-front requirements and bidding document preparation. In order to assure all vendors provide comparable bids, considerable time needs to be spent, by your in-house team specifying both the project and the vendor requirements. If a number of non-compliant or non-comparable bids are returned, what is the cost of going back to the vendor with more details and allowing other vendors to update their bids with what is perhaps new information or different assumptions for them? The hourly cost of internal staff, consultants or both add up but are often not counted in the final project analysis.
- Time and opportunity costs. Depending on the value of the project, the vendor selection process can take 4 months to a year. This includes selecting the vendor pool, preparing documents, sending, receiving and reviewing documents, negotiating and preparing contracts, demonstrations, travel to selected vendors, and more.
- Travel costs. To properly evaluate final round vendors for a strategic project, it is imperative that is spent at the data center or workplace of the vendor team to assure that practices and conditions match expectations. The greater the distance, the greater the actual costs and the time required for travel. Typical round-trip times to India and Asian locations are two to three weeks depending on the goals and number of vendors to be visited.
#3 Project initiation
The costs of project initiation have an inverse relationship with project risk. The less you spend on project initiation, bringing the teams together, assessing process and methodology, assuring communication, respect, and team collaboration is strong, and that there is a shared understanding of project goals, the greater the risk that the project will fail. But even knowing this simple fact, most vendors and buyers will decide to cut the project initiation phase in favor of “getting to productive coding” quickly. The downside of this choice is a longer time to reach full productivity, more risk of rework to meet expectations, and increased costs for project oversight and team management.
#4 Staff transition
When a new outsourcing team is started on a project, internal staff is often given new roles as part of the initiative. They could be tasked as product owners, to oversee user story development, to run internal quality and acceptance testing, or to assure that questions that cannot be handled directly by the internal product team are handled quickly by the right subject matter experts. If the outsourced team cannot work during the standard workday of the client team, the daily schedules of the internal team may have to be shifted drastically. Their existing roles and responsibilities will need to be handed off or reprioritized to allow them the time to handle their new work and the task switching that invariably occurs. The costs of transition (and retraining in the case of those that may be new to methodologies like agile) are rarely considered in project costs but in reality, if they are not allowed for, the resulting issues can be very costly.
#5 Infrastructure & operations realignment
Inevitably, a new outsourcing project will incur changes in local infrastructure and software development operations. The changes may include new virtual environments, changes to internal processes for continuous integration, automated testing, security and authentication, incremental releases to production or many other issues. Again, part of this falls to poorly planned project initiation, but even with upfront time focused on team cohesion and user stories, the requirements for infrastructure and operations are often overlooked. When they are, count on additional costs because of lowered productivity as issues are ironed out and everyone gets on the same page.
#6 Contract & relationship management
Throughout the project, the buyer/client-side project manager needs to assure that incremental payments match the effort spent and the deliverables received as well as the necessary progress toward completion. Not spending enough time on this aspect of the project can result in very tough negotiations if the project goes off track or unexpected issues arise. In addition, selecting the right project model, whether it is fixed price, time and materials, dedicated team or another variation, has a big impact on this area. A lack of trust and understanding or lack of partner-level communication during the project can make a project very hard to manage to a successful conclusion and very costly when issues must be resolved.
#7 Cultural & organizational alignment
It may seem like a “soft” issue, but if the outsourced team and vendor cannot navigate your cultural norms and organizational environment it is likely to make project management very difficult. Bringing a team from a hierarchical culture into an organization with a flat structure can be very disorienting to team members with different expectations for interaction and responsibility. Merging a small team into an enterprise system with many silos and layers of control can be very difficult. The new team in either case will require additional time to reach full productivity and oversight to ensure they can fully participate as expected – and has a real cost.
#8 Intermediaries
To mitigate many of the issues in this list, outsourcing vendors and buyers often impose intermediaries on projects as an extra layer of “assurance.” This imposes two extra layers of cost on a project: The direct cost of the extra labor required and the indirect cost from the risk incurred when developers, product owners and subject matter experts do not regularly engage in project discussions directly. Every time an intermediary becomes involved, there is a loss of fidelity and clarity. In the end, instead of assuring better communication, the sides are pulled into a “blame-game” when issues are not fully explored or questions are “translated, collated and summarized.”
#9 Technologies
The selection of technologies for a new project can have significant impact on project and application success. If the internal team restricts choices because of a lack of understanding and confidence in the options offered by the outsourcing team, if a lack of communication results in a poor understanding of risk and downsides of technologies selected, or if choices are avoided to keep from exposing a lack of awareness – the downsides can be very hard to overcome. They can raise “technical debt” to a degree that limits options “down the road” in the project or the application lifecycle and lower team cohesion to the point that trust and communication are lost completely.
#10 Location, location, location
To a degree, we’ve covered this already in the sense that work time overlaps, cultural fit, and communication issues can cause project costs to rise significantly. But on its own, the location of the outsourcing team in relation to the client team should be a part of vendor selection, a factor in project initiation, and a major concern from the beginning of any outsourcing relationship. The greater the geographic distance between the teams, the greater the issues will be. Mitigation costs, in general, will increase including travel, working hour adjustment, intermediaries, communication, contract management, etc. While considering nearshore vendors will not eliminate all outsourcing risks and issues, they can make other choices much easier to deal with and diminish risks significantly if they have the right resources and ability to work at a partner level with your team.
Outsourcing can save you time and money, but only if it’s done correctly. With so many factors to consider, it’s important that you do your research before making any decisions. The 10 points above are a great starting point – but there are still more software development costs to think about, such as marketing development costs and advertising expenses. By taking the time to understand all of the possible hidden costs associated with outsourcing, you can be sure that you’re not overspending on your project.
Scio is a nearshore vendor of software development services for our clients in North America. We tune our project model to the project at hand and operate with our clients at a partner level to lower risk on both sides. If you would like to discuss your next project and the options we can offer, please contact us. We would be happy to work with you.
by Scio Team | Apr 18, 2016 | Agile Methodology, Customer Experience, Nearshore, Successful Outsourcing
In one sense or another, we’ve all heard the term “body shop.” In the world of automobiles and mechanics, it refers to a shop that repairs or modifies car bodies, but in software development, it refers to outsourcing vendors who use contract labor to fill their requirements. Let’s say at the outset, this isn’t an inherently bad practice. Many, if not most, larger vendors started out as body shops (0r temporary staffing providers – another similar term) and eventually grew beyond the practice. There are many well-established vendors who are essentially filling the place of in-house recruiters and have a network of contractors they have used repeatedly that make the process of filling short-term needs an easy job for their clients.
But, the problems start when an outsourcing vendor doesn’t disclose their business model and you assume from their website or on the basis of a phone call that they are offering a team for a software development project that has a full-service house behind it.
What’s the difference?
In most cases, a full-service outsourcing provider can offer:
- In-house staff – Trained, supported, and backed by an organizational structure that includes infrastructure, formal methodologies, processes, and benefits that promote success and staff longevity.
- Organizational-level expertise in technology, verticals, project planning and initiation, risk management, automated testing, and other areas that make their teams more robust and create a better opportunity for project success.
- The ability to shift quickly to fill a team role if a resource becomes unable to finish a project for some reason. Generally, established vendors have some “bench” – resources not fully committed to existing projects that can step in when needed. Because the technologies, methodologies, and processes they use are formally supported in the organization, staff members that join a project after initiation are likely to be able to get up to speed relatively quickly.
- Established infrastructure (virtual and physical) including up-to-date workstations, secure Internet connections, managed IT resources, and the project-level resources necessary to support development operations such as continuous integration, testing automation, shared repositories, VPN connections, etc. When these resources are already in place, there are practices in place to operate and maintain them, setting up a secure, reliable project structure is relatively easy and the resulting operations are robust, reliable and secure.
Body shops generally offer:
Relatively quick access to individual resources or the ability to pull together small teams from contractors. Most cannot offer a great deal in the way of project planning – their business model is to provide experienced resources, whose resumes, skills, rates, and availability have been checked – not to provide full-service for longer-term engagements.- They may offer some level of infrastructure at the organizational level, mostly virtual, but since their resources are generally remote, this means they will have difficulty providing the same level of security, methodology, and practices that you would find in a full-service vendor with a data center.
- Relatively low-cost resources for short term, well-defined engagements. They offer little in the way of project oversight so it is incumbent on their clients to provide the project planning, requirements, and organizational resources the project needs.
When Things Go Wrong
As we mentioned earlier, projects go off the tracks when you assume or are told your vendor’s business model is one thing and it turns out it is another. If you go to a full-service provider to fill a spot need (a few weeks to a month with one or two resources) you are likely to be surprised when you read the quote. Their proposal will generally include options or steps you might have assumed you would do in-house or weren’t needed. Their resources will be more expensive when compared on skills and experience and their value will be harder to judge against vendors who do not have the same level of overhead, staff and organizational support.
If you go to a body shop and expect the vendor to be able to provide an experienced team for a longer engagement, you are likely to be surprised that you are expected to take responsibility for bringing together everything needed to ensure the project operates with industry-standard methodologies and the team collaborates in ways that provide strong production metrics, reliable and maintainable code and proactively manages risks while avoiding “feature creep.”
There are a lot more things that could be said about picking a software development outsourcing partner with a business model that is not suited to your needs, but the point is – when you don’t know what you need or what the vendor is really offering – the outcome can be more expensive and less successful than it should be.
If you don’t ask, most vendor sales are likely to be opportunistic. They want more business above all and will present the picture they think you are looking for. Somebody shops will provide resumes on their letterhead to make it appear the resources are in-house. They might even go so far as to recast past experience as “in-house” when in fact the contractor offered was working directly or for another provider. Some full-service vendors will offer junior resources for short assignments or staff from the bench that cannot be committed more than a few hours or days at a time. They aren’t being “dishonest” – they are trying to get full utilization and lower their overhead, but in the end, if you call them back for that resource again, they may be unable to break them loose. The same may be said of the body shop, however, since they generally cannot fill the available hours of their contractors for every day of the year, they will often have to substitute with another resource if you need to bring someone back to continue work.
The Right Vendor for the Need
All this comes down to one thing – regardless of your need, you need to have outsourcing vendors whose business model you understand and that gives you the ability to use the one that fits the need you are resourcing. This means having conversations, relationships, with your vendors and establishing a partner-level dialogue so you have confidence in what they can do for you successfully. It takes time and attention throughout the relationship to maintain the level of communication needed and it should be as much from the vendor as from you. But, if you can establish partnerships with your outsourcing vendors, the outcomes should be better for both sides.
In that “best case” scenario you might use your “body shop” partner to provide:
- Spot resources to fill short term needs within your own teams or to bring a specific skill when needed that is otherwise time-consuming to find and contract.
- Low-cost resources that you plan to manage in-house and provide whatever they need to be successful in working with you.
- Replace positions lost through attrition, illness, vacations, etc. while you search for permanent replacements.
And you could use your full-service development shop partner to provide:
- Small to large experienced teams to become an integrated but largely self-sufficient part of your operations that can be responsible for strategic projects without straining your internal staff.
- Agile project teams that can use the methodology effectively to develop less defined but critical applications collaboratively with your staff.
- Dedicated teams that work as a part of your larger DevOps system for continuous app development either as part of enterprise or product teams for client-facing applications.
Either scenario represents putting your outsourcing partner’s business model to the best use for your needs, not bending either one into a configuration that could be a bad fit for both you and your service partner. If your organization is small or a startup, it may seem like a lot to take on to take the first step, establishing a partner-level relationship but in the long run, even a small operation can benefit from an atmosphere of shared understanding and trust – perhaps even more than enterprise-level organizations who have more leeway for risk.
Scio is a full-service, nearshore provider for software development outsourcing to our clients in North America. We seek partner-level relationships with our clients to help us provide the right services tuned to their needs over the long run with less risk and better project outcomes. Whether you are unsure where your needs fit or you have a clear idea of how to resource your project, please consider contacting us to discuss what our services can offer you. We would be happy to work with you.
What does our measurement tell us? What is it not telling us? If we are measuring lines of code or functions, is the measurement telling us if the work was efficient or just an output meant to produce more (or a given number of) lines/functions over a given period? Were the lines of code or functions really efficient and useful? Programming is very comparable to writing. Some writers are more efficient at expressing thought and others see a more elegant way to express a thought without addressing it directly. Some programmers are more efficient because they reuse code multiple times throughout the source with efficient use of variables. Some functions in a program are critical and getting them right is tough, requiring time and effort. Other functions are simply “eye-wash” and don’t have a real bottom-line value. There as many ways to game the system as there are ways to produce better code with fewer lines. Every programmer, every team, and every project has different dynamics depending on the language being used, the type of environment, the technical problem being dealt with and many other factors. If you use a pure “number of X metric,” you have to be clear about what it means and doesn’t address.
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.
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.
To understand the differences between the two cultures, take a look at a comparison between the US and Mexico as outlined by studies done by the 
In one sense or another, we’ve all heard the term “body shop.” In the world of automobiles and mechanics, it refers to a shop that repairs or modifies car bodies, but in software development, it refers to outsourcing vendors who use contract labor to fill their requirements. Let’s say at the outset, this isn’t an inherently bad practice. Many, if not most, larger vendors started out as body shops (0r temporary staffing providers – another similar term) and eventually grew beyond the practice. There are many well-established vendors who are essentially filling the place of in-house recruiters and have a network of contractors they have used repeatedly that make the process of filling short-term needs an easy job for their clients.
Relatively quick access to individual resources or the ability to pull together small teams from contractors. Most cannot offer a great deal in the way of project planning – their business model is to provide experienced resources, whose resumes, skills, rates, and availability have been checked – not to provide full-service for longer-term engagements.
As we mentioned earlier, projects go off the tracks when you assume or are told your vendor’s business model is one thing and it turns out it is another. If you go to a full-service provider to fill a spot need (a few weeks to a month with one or two resources) you are likely to be surprised when you read the quote. Their proposal will generally include options or steps you might have assumed you would do in-house or weren’t needed. Their resources will be more expensive when compared on skills and experience and their value will be harder to judge against vendors who do not have the same level of overhead, staff and organizational support.