What is TCE?

Generally, when someone starts looking for resources to fill an outsourcing assignment – the first thing they do is start looking at “comparables.” In the case of a director of engineering or technical manager, they have a good idea of the types of resources and skills they need and if they have internal staff in similar positions, with similar skills, they know what they are paying and what it takes to find the resources and bring them up to a productive level in-house. What they may not have is a broader picture of market pricing for outsourced resources. To budget properly for an outsourced team, rather than a single resource to do a short, spot assignment, costs beyond the hourly quote for the resource need to be understood and included.

So what needs to be considered to arrive at a reasonable estimation of the total costs of an outsourcing engagement?

Level the playing field

Primarily, what we’re looking for are the costs that are not included in a quote from a provider. For the moment – let’s limit ourselves to quotes from companies that will provide an entire team. We’re not going to consider going out to find individual contractors, one-by-one, because that is not very efficient for an engagement with a longer period than a few weeks. You are taking on all the recruiting, team training, project organization, project management, risk and employee overhead. If you are going to do that, you might as well recruit them as an in-house team. That isn’t to say that this isn’t a useful comparison for the outsourcing engagement, but when you total the comparative costs – all the costs of directly bringing on contractors – including contributions to medical, unemployment and disability, vacation, sick time, infrastructure, floor space, computers, software, etc. it becomes a big number quickly. In the end, for longer assignments and larger teams, it is very close to the costs of direct hires. A lot of companies will have a good guide in their financials, but not broken out in a way that the overhead per employee is easily adapted for comparison purposes.

In addition, you need to consider what kind of provider would work in your situation. There are many types of providers and some offer more in their quote than others. A full-service development company with an in-house development center and full-time staff, inherently has more to offer, and consequently more overhead, than a standard staffing company. Generally, a staffing company will have “regular contractors” that it knows and trusts that it can bring to the table for more profitable engagements. But, it will not have a data center as such and the contractors may be spread across a large geography. You can usually specify that you want them to all be within a certain area (even within driving distance for instance) or to have certain characteristics (conversational and written English, direct access to the internet, their own up-to-date equipment, etc.). Most staffing companies offer resources that have been tested for skills independently and that have specific experience as well, but all these conditions limit the pool of available resources and will necessarily raise your end costs depending on your flexibility. So, if you are going to include staffing companies in your comparison, be sure you specify clearly the limitations they have to work with and you understand the responsibilities you are taking on for that category of vendors.

When it comes to full-service development companies, again be sure you are comparing apples-to-apples. Some companies are really just groups of developers that work together frequently and present themselves as a team. That isn’t to say they aren’t qualified and perhaps right for your situation, but it does mean you have to ask them to speak honestly so you can be sure you understand the limitations of the services they can offer. Do they have a corporate structure? Do they have the assets and can they handle problems if the project lags or they have a resource that becomes unavailable? Can they offer any guarantees for your intellectual property (IP) and quality of work? Again, the main reason to consider these issues is to know what you are taking on in your overhead and risk so you can compare different scenarios with clarity. You may decide to walk away from some situations when you have a good understanding of the limitations, but that is beyond the financial comparison we’re discussing. And when it comes down to it, as you will see, you shouldn’t be afraid to assign costs in the leveling exercise. As an example, if using an offshore group requires some employees to work different hours, more supervision, or higher travel costs, the key is to assign costs to those differences and understand their impact on the engagement.

Finally, as part of the leveling, we’re going to assume the same size team, resource requirements, project specifications, and project type across all options. So, if we want our team to work using agile methodology, we’re not going to directly compare a quote from a team that does not offer that as part of their service, without assigning some cost, perhaps a risk-based cost in this case, to that difference. For this reason, historical costs of past projects might not provide the guidance they seem to at first. If you didn’t actively manage project-related costs, they may be buried in other departmental costs or expenses that are not directly accounted for in project costs.

Where is my team when I need them or they need me?

It is certainly possible to collocate an outsourced team with your in-house development team. Depending on your location and resource availability, it is often more expensive than using an outsourced team in an area with lower costs, but it can offer better communication and more direct involvement across your team. But putting the cost aside for a moment, unless your needs are pretty straightforward, and you are in an area with many competitive companies that can fill the need, finding a team with the skills and experience you need can require a long search.

Opening the door to a global market brings a lot of competitive offerings to the table and with them, many questions:

  • If the work is to maintain or extend existing applications, knowledge transfer and training will certainly be a key part of the ramp-up to productivity. Assuming at least part of your internal team will be involved, there will also be a loss of time and productivity in their regular work. If the outsourced team is within reasonable travel distance, it is usually best to either bring them to your location for the knowledge transfer, or have at least part of your team travel to their data center. Either way, the greater the distance between your location and the outsourced team, the greater the cost will be to cover travel, time and lost productivity. What will this amount add to your TCE for the project?
  • If the work is for a completely new application or product, it is still advisable to bring the two teams (internal and outsourced) together, but the interaction will be more focused on the application requirements and development operations. The knowledge transfer required will likely be based on understanding the business model for the application and to some degree at least, the client. How much cost are you allocating to this? No one can hit the ground “running” without at least some runway.
  • In  either case, the need to bring teams together and to communicate continuously during the project means that if they are within the same geography or continent, the shared work hours during a business work day will make it much easier and allow you to focus more on the aspects of development operations and team interaction during the initial phases of the engagement – rather than tight specifications and details. For many situations, this means that a team within a few time zones could have a lower total cost even though the hourly rates are higher than offshore teams in Asia, Eastern Europe and India. Real-time communication and a shared understanding of the value of asking questions directly to ensure everyone is on the same page is often underrated or ignored in costs. If the lack of communication between the teams causes a loss in quality or productivity and increases the need for rework because there is a lack of fidelity in understanding between the teams, it has a cost and should be considered in the TCE. Having to wait twelve or more hours for a complete cycle of communication has a cost, both in productivity and risk. In software development projects using agile, it means that a lot of fidelity will be lost unless some very special adaptations are implemented.

Six areas of cost and risk mitigation that should be mapped into your TCE

So, let’s look at six points that can make or break an outsourcing engagement if they aren’t recognized, accounted for and controlled as a part of the total cost:

  • Total Cost of EngagementTravel Costs – At the start of any software development engagement, there needs to be an initial meeting to get everyone on the same page, to know and trust each other, to quickly clear any operational issues, deal with knowledge transfer and to clearly understand the work in front of them. The amount of time required depends on many factors, but dealing with these issues is always more efficient when everyone can work face-to-face. Costs to be considered vary depending on whether it is feasible to bring the outsourced team to the client or key members of the client team to the outsourced development center. Included in those variables should be visa costs (especially for even small teams coming into the US from overseas locations), round-trip airfares, hotels, meals, and ground transportation. In addition, you need to add costs for lost time and productivity on your regular workload. For offshore locations, it is not unusual to lose a week on either side of the trip, including time to deal with travel paperwork and jet lag. For longer engagements or to deal with critical issues, more than one trip may be required – with additional costs of course.
  • Risk and Contingency Management – Although it is critical to understand the risk you are taking on in any outsourcing project, it can be hard to translate risk and contingency management to costs. The simplest answer is to cost the mitigation you will undertake because of the issues you anticipate. If you’re not planning mitigation, you’re not prepared for the scenarios you understand could be the difference between success and failure. Among the issues to consider are:
    • Release System – In projects that involve existing applications or dependent parts of suites of apps in release, the release system can create serious overhead for a software development team. Many times in this situation, testing does not completely duplicate the production environment. When the actual data cannot be used (as is often the case in financial, security, and healthcare applications), unexpected cases can appear in production data that don’t appear in test. When the release and acceptance cycle is long, as it can be when it involves more than one data center or client environment, often the development team will continue to the next phase of work, rather than waiting for the results of the release to come back. If code management and testing are not fully automated, this can result in serious issues when a problem is detected that has an effect on a piece of critical code for many parts of the app. When the outsourced team is located offshore or is unavailable for some period of time to assess and apply fixes, problems can cascade through production bringing operational productivity down, if not stopping it all together. The technical systems and development operations approaches to mitigate these issues are well understood, but all of them have a cost in licensing (where needed), implementing, training, and maintenance.
    • Changes in Direction – If a project team cannot respond easily to opportunities or business forces that present opportunities to change an application or the business goals it embodies, the project can lose its viability and position in organizational strategy. The problem comes down to communication and a clear understanding of the overriding priorities of the client organization. If contracts are too tight, if the agile or similar methodologies that provide methods to manage changes in direction are not in place, the work required to negotiate and make a significant change can be overwhelming. Establishing how change will be managed and how productivity can be protected while change is managed is a key part of early project planning and negotiation for any outsourced development project.
    • Response to Issues – Not all situations require a change in the direction of a project. Some issues are just spot clarifications of meaning or outcomes. Some are minor at the time they are identified, but can mushroom if not addressed quickly. Responding effectively to issues means that lines of communication between members of the development team and product managers must be open and trustful. If there are layers of technical and operational management that slow down, prioritize and “translate” communication, fidelity will be lost and many important issues will fail to be addressed properly. Technical systems are important of course, but open, honest and direct conversation is the critical element of both transmitting and hearing the issues that are creating barriers to productivity and success. If that means that the teams need some face time together to reach a level of trust, it will have a cost, but it will mitigate many problems that could be much more costly down the road.
    • Total Cost of EngagementGeopolitical Risks – It used to be that we worried more about political upheaval than we did catastrophic weather, but now the risks are about equal. In places where infrastructure is weak, flooding and winds can cause considerable disruption. In places where considerable headway was being made to provide a platform for outsourcing, like the Ukraine in Europe, political change and war can quickly change the situation from positive to very negative. Increasingly, there is no perfect answer that will mitigate all risks. A major storm can hit the US Eastern seaboard and wipe out communications and even major data centers for a period of days or weeks. Certainly, failover data centers can be and should be used where the cost is not prohibitive. Progressive backups of code can be made nightly to secondary data sites by automated scripts. This won’t replace a remote team that is unable to communicate in a major situation, but it will make the steps needed to get back to production much easier in the end. Again, early planning and inclusion of appropriate mitigation in development operations is key.
    • IP Protection – Intellectual Property (IP) is generally part of any outsourced software development project. It can be embodied in the actual code developed, the data the application uses and produces, the business rules, methods and procedures used, the security and technical systems employed, and many more areas. Generally, the first level of protection is part of the contracts between the parties to the engagement, backed-up by international treaties and agreements that provide a basis for enforcement. Beyond that level, you may decide that the critical nature of your IP requires layers of security and control that have a cost, but that will provide legal and technical assurance that you have properly protected your systems and data. The cost of mitigation in this case often depends on how much trust you have in the environment and situation and how long it would take you to react to an issue. If you control security and your data systems, you bear a significant burden in cost and risk, but in the end, it may be no more than you should have to assure protection in normal operation today.
  • Cost of Knowledge Transfer – While documentation is part of any knowledge transfer effort, the truth is that the more documentation is depended on, the less efficient it will be in providing good information to your team when they need it. How can you assure when a member of your outsourced team reads a section of your documentation, they will completely understand the context it is presented in? If they are using it as a spot reference, they may or may not have read important, related documentation. And of course, once you have gone to the trouble of developing comprehensive documentation to support your team, who is going to maintain it properly? The answer, of course, is to rely on written documentation only as much as you have to. Consider instead improving the efficiency of person-to-person interaction from the start of the project and all the way through. This can mean anything from direct meetings to daily real-time communication. Although it is possible to have a cultural disconnect between any two groups of people, the more they work together and communicate, the more likely they are to develop understanding and trust between them. If someone has a question or needs clarification, assuring that they don’t feel they are putting themselves in a bad position by bringing up the situation and asking for more information, is critical. There is no time more important than the moment when someone is unsure or questioning a situation, to initiate a respectful conversation about the problem.
  • Productivity Loss – In many outsourcing situations, the working hours of the teams are separated by several time zones, or by their understanding of language and terms, or their ease with direct reporting to someone in another company and perhaps another culture. In these situations, one team or the other will often add additional project management as a bridge or intermediaries that relay, translate, route or prioritize communication instead of finding better ways to communicate directly.  As more layers that are added to the communication chain, more friction will occur, time will be lost and the fidelity of interaction will suffer. These additional layers have a cost, in headcount and productivity, you need to account for or find ways to eliminate.
  • Attrition and Team Churn – Of course, the longer an engagement continues, the more likely it will be that at some point, some members of the team will need to change. Even if they don’t have other opportunities, life events can create problems that will require a move or need to change their working situation. When this happens, there will be a time required to find a qualified new resource, and a loss of productivity while the position is empty or a replacement is trained, integrated into the team, and brought up to speed. This is a normal part of all team dynamics, so recognizing that it can and will happen and putting in place the plans and agreements necessary to assure the least amount of disruption is worth the effort and cost.
  • Management Overhead – Considering the rest of the areas of concern, you had to see this one coming. If your response to dealing with the issues around projects and outsourcing is to add more management overhead, or require it from the outsourcing contractor, you can’t be surprised when the project cost of engagement rises. Intermediaries, even in situations where the base cost of labor is quite low, add cost, friction and lower productivity. Whether the outsourced team is collocated with your team or on a different continent, it creates a situation where the development team itself is less responsible for ensuring communication and productivity. The rule becomes, if things are not going right, talk to the intermediaries, don’t bother the team. A situation like this lowers team and individual responsibility and does nothing to improve collaboration, quality or productivity. Agile, as it should be practiced, enforces responsibility and team commitment. Don’t initiate overhead that takes it away.

Although we have discussed several areas, we have by no means exhausted the possible costs that could be included in your TCE. But on the other hand, the fact that all costs are not included in provider quotes should not deter you from outsourcing your next project. What it should do is make you ask more questions and be more deliberate in comparing service offerings.

Scio is a full-service provider of nearshore-based, software development services. Although using a nearshore provider for your next project will not eliminate all the costs and risks of your next project, we invite you to compare the total cost of engagement with a nearshore provider against the cost of offshore and local resources. Because of our range of services and resources, we won’t claim to be the least expensive offering on an hourly basis, but we think when you compare total costs – our offerings will be very competitive.