Subscribe
Share
Share
Embed
Welcome to the Ksense Technology Podcast where we discuss the trends in software development, web applications, and how custom software can help businesses scale. Ksense is a full-stack software development company using state-of-the-art technologies to build cutting-edge applications. With over a decade of software development experience, our team is confident we will deliver results for your organization.
[Kelson] (0:00 - 0:08)
You do save money by taking your project outside the U.S., but I think it's interesting to talk about how much you actually save.
[David] (0:08 - 1:00)
The turnover, the communication, the quality ends up dragging out the project. This is a really common experience when you're outsourcing a job globally and you're just looking for the cheapest work you can get. Welcome to the podcast, everybody.
I'm here today with Kelson Irwin. He's the CEO at Ksense Technology Group. Today we're talking about whether you should go with offshore or USA software developers, especially when you're outsourcing a software project.
We've had some conversations in the past, Kelson, about this. I understand today you really wanted to clarify some points and really bring some data, some information to people that can clarify what the pros and cons are and really help people who are making this decision. Thanks for joining me today.
[Kelson] (1:00 - 1:02)
Yeah, awesome. I'm excited to talk about this.
[David] (1:03 - 1:17)
Great. I wonder if you could just give me a little bit of context, what the difference is between offshore and USA-based teams and just some foundation for this conversation of what people should be thinking about.
[Kelson] (1:18 - 2:39)
Yeah. Specifically, my expertise is in software development. Generally, when we're talking about different agencies and outsourcing, we're talking about choosing an agency in the US.
Offshore means India, China, and then there's near shore, which is usually considered to be Latin America. Those are the different types of agencies that you can get. One thing to address up front is that I do have a little bit of a personal bias.
My entire software team is US-based, so that's something to keep in mind. There's also a bit of a tendency to stereotype or overgeneralize when you're talking about different regions of the world. While some of these generalizations are based on trends and data, it's important to remember they don't apply universally.
The industry is super diverse and there's exceptional professionals worldwide. I'm going to try to put out all the facts and then some of the trends that we see, but I'd like to apologize if I do stereotype during the conversation.
[David] (2:40 - 3:10)
That's a really good point. This is really just for practical purposes as people are trying to make these decisions. What are the things that they should be looking out for?
What are the pros and cons? I think a great way to start it off is just talking about cost. That's really where people go first in this conversation.
What's the cost difference? Is it cheaper if I just hire somebody somewhere else in the world to do my project? What would you say to somebody who's asking that question?
[Kelson] (3:11 - 5:38)
I think the main reason that most people decide to outsource outside the USA is for cost-saving purposes. If you look at the cost of a senior developer in the United States, it's around $120,000 to $180,000, whereas offshore in India, you can get a senior developer for around $40,000. Then in Latin America, it's about $50,000, so it's a little bit more expensive.
What we're seeing is that the primary motivator for most businesses to outsource is the cost-savings purposes, but there's also some other reasons why companies might outsource. That would be that it's a little bit easier to find specialized talents, especially when you're looking for really specific skill sets. Like specialization.
Yeah, like a deep level of specialization. Sometimes you can find those more outside the United States, or it might be difficult to find them outside the US. Makes sense.
One thing that is important to mention, and a lot of data backs this up, you do save money by taking your project outside the US, but I think it's interesting to talk about how much you actually save because if we look at the salaries, in the US, it's $120,000, and in India, it's $40,000. What we find, and there's been numerous studies that back this up, one study that I'll cite here is the Journal of Business Research, and it's titled Offshore Outsourcing and Firm Performance, Moderating Effects of Size Growth and Slack Resources. What it talks about is the total cost of ownership, not the hourly cost, but the total cost.
It shows that after everything's considered, the actual cost savings is about 10% to 15%. Whereas, if you looked at just the yearly salary or the hourly rate of the team, it might look like India's three times cheaper, but you actually don't save that much over the long term is what we show, and that could be due to the fact that it starts off cheap and it gets more expensive over time due to different hidden costs.
[David] (5:41 - 5:45)
What are those hidden costs? What kind of costs might surprise people?
[Kelson] (5:46 - 6:33)
I think there's hidden costs in miscommunications that lead to quality assurance issues. There's a lot more things you have to put into a project management system to deal with time zones, and if you decide to travel for face-to-face meetings, there's costs there. There's also costs associated with training that can be higher for offshore teams, and then there's also the higher turnover that we see, the cost to secure all your data and to work with all the different IP legislation for the area that you're working in.
Those are some of hidden costs that we see that ends up bringing the price up.
[David] (6:34 - 7:24)
I know that we had a project that was pretty simple that we outsourced, and we decided to outsource it because it was simple. In the long run, we ended up going through... I think we've already gone through two contractors attempting it, and we're probably looking for a third right now.
That's part of it. Like you're saying, the turnover, the communication, the quality ends up dragging out the project. Again, generalizing, right?
But this is a really common experience when you're outsourcing a job globally, and you're just looking for the cheapest work you can get. Yeah, that makes sense. You really have to balance the risk of cost with the risk of timeline, and actually, what is this thing supposed to be accomplishing for you, and how badly do you need it, and do you need it to work really well?
[Kelson] (7:24 - 8:14)
Yeah, and we'll talk about how to mitigate some of the challenges that come with hiring an offshore team, but funny enough, the reason that I have a U.S.-based team is largely due to those problems. Obviously, when I was starting this organization, I wanted to build software as cheaply as possible because then I can make more money. I can charge my clients in U.S. dollars and pay somebody in pesos or rupees or whatever, and that's really the way to maximize profits. But there were just so many problems with the implementation of that that I decided that it's better for me and for my customers to just go with a U.S.-based team. I've actually had success working with offshore teams before. We'll talk about in what cases I think it's appropriate and which cases I don't later on in the conversation.
[David] (8:15 - 8:29)
Yeah, so part of the cost conversation brings up quality. Let's dive into that a little bit more. What are some of the quality differences that you see between offshore outsourced projects versus projects that are completed by U.S. developers?
[Kelson] (8:29 - 11:06)
Yeah, so I think there's a lot of things that we can tie into the word quality, right? The quality of working with the agency or the quality of the product that they're developing. But to kind of wrap it up, there's a lot of issues that come with offshore teams not having a great understanding of how United States businesses work.
For example, if you're doing anything with finance or anything with law, you know, the systems in other countries are very different than our own, and it's important to realize that. It's also, you know, the work styles might be different and the culture is also different. In terms of the product and the project management, if you have English as a first language, which we do here in the U.S. for most people that you're going to hire, you tend to have less misunderstandings, which results in a more accurate implementation of your project requirements. The developers in the U.S. have a lot more exposure to the newest and most cutting-edge technologies, and that's because the tutorials, they come out in English. A lot of tools come out in the U.S. before they come out in other countries. We're a lot closer to all of the biggest tech leaders and organizations in the world.
You know, we have Silicon Valley, and, you know, we have a lot more people that are experienced with the biggest applications in the world, at the largest scale. You know, to kind of reiterate on the generalization thing, this is a little bit of a generalization, and, you know, you could have all these things that are true with somebody that's outside the U.S. as well, but those are kind of the trends that we see that results in having a better product when you hire in the U.S. There may be a little bit of a difference in education and training standards, different ways that people are educated, you know, and then, you know, like I said, we had some challenges with hiring offshore, largely due to these types of issues, right? We had a lot of miscommunications.
The implementation was antiquated. You know, this is just something that we've heard about and seen a lot, and it's not really no fault of the agency itself. It's just, you know, a lot of times the we live in, right?
If you grow up in Silicon Valley, you're probably going to have better exposure to the newest and most modern technologies.
[David] (11:06 - 11:43)
Yeah, and probably just like business acumen, you know, just generally understanding, like you said, knowing how businesses work in the U.S., but also how people talk about them, right? Somebody who's a leader at a business has a certain way of talking about their project, talking about why it's a priority, what they're trying to out of it. And yeah, I've definitely seen that with, you know, even talented engineers whose level of English skill just wasn't high enough to fully get what the person was saying and what they were trying to accomplish, even though they could, you know, technically, they knew how to do the work.
So yeah, that's big.
[Kelson] (11:43 - 11:44)
100%, yeah.
[David] (11:44 - 11:53)
So what sort of challenges do people commonly run into when trying to communicate about their projects with offshore teams? How do you address those challenges?
[Kelson] (11:53 - 14:55)
That's a great question. So the complaints we hear the most often usually has to do with time zone differences. If you're working with India, you know, any of the offshore, which would be like India, Europe, China, they're on the other side of the world most time.
That makes it so that everything oftentimes works a little bit slower, takes longer to get responses to emails. You know, it ends up making the project take longer, especially where in a lot of cultures, they're kind of email first instead of like Slack first or whatever. You know, so that's been a challenge.
One thing that some organizations do is they use a follow the sun development approach, which is essentially where they have small teams in several different countries that work on the application, and so, you know, while we're over here sleeping, there's somebody offshore working on the project, and then it gets transferred to Europe, and then when Europe's sleeping, and then it goes to the U.S., and so you have people working on it essentially 24-7, which is really cool, and it's a really creative solution to the problem of the time zone differences.
I've just seen that it's incredibly difficult to pull off well. You have to have like a really strong leader and very good documentation on how everything needs to work in terms of project management, in terms of handoff, in terms of communication. You know, it definitely, I think there's a lot more room for there to be miscommunication, especially, you know, the more languages you get involved, the more different cultures you get involved.
It's just can be challenging, but I've heard it. It's been done. I haven't talked to anybody that's done it personally, but I've heard it's been done, and it is a very cool idea, and I think that in a perfect world, that's what we would all be doing, so that's, you know, that's definitely one of the challenges and the most complained about.
The other challenge has to do with some cultural nuance, and I think this boils down to a few different things. One of them is the different communication styles between countries. In the U.S., we are very direct with our communication style. We would say something like, hey, this approach is not going to work. We need to change it, whereas, you know, in other countries, they might say something a little bit more indirect like, this approach is pretty interesting. Have we considered all the alternatives?
And I think that there's a little bit of an issue there because the indirect communication style can get overlooked more easily, which can cause problems and miscommunications. I don't know, David, have you ever experienced that before when you said you were working with some offshore teams?
[David] (14:56 - 15:37)
Yeah, I've experienced that. I've also experienced it in the other direction, where I think in Latin America, for example, sometimes they can be even more direct than the American common cultural communication style. So yeah, it goes both ways.
Sometimes there's just those cultural nuances that unless you've spent some time there and you really understand how they communicate with each other, it's just not going to flow smoothly. You're just going to get confused here and there. You're going to go, oh, wait, you know, if they were saying that was important, why didn't they put more emphasis on that?
Why weren't they more clear about it? And in their mind, they were super clear. So yeah, I've definitely seen that.
[Kelson] (15:37 - 17:54)
Yeah, exactly. And then there's also the differences in how you treat your superior. For example, in the United States, I think it's a lot more acceptable to challenge ideas that your supervisor has, whereas in especially Asia, there seems to be more of a tendency to hesitate contradicting anything that your superior might say.
And in India as well. And again, these are kind of trends and generalizations to a degree. But from my experience, this is kind of what I've seen.
The different attitudes towards superiors can also cause issues, especially if the cultural nuance is to be more of a yes man. You know, what you can find out is that they're spinning the wheels. They told you, yeah, of course, that's possible.
But they're afraid to come and tell you, hey, it's not that this is impossible. It can't work this way. And so they end up spending a lot more time on your project.
And so that's something that I've seen before, especially in some of the projects that I've worked on in the past, where we had somebody on the team and essentially, they were always worried to tell us about any problem with the application, you know, kind of goes back to the miscommunication point and the quality and the quality of working with the team and the quality of the product. A couple of other cultural nuances would be work-life balance. In other countries, there's a tendency for them to work a lot more hours, which can result in burnout, which obviously is going to affect your project.
It's going to affect your relationship with the agency. It also results in higher turnover. So there's more training costs.
And then you have other countries like France that don't work as much. And so or a lot of Europe has a lot more holidays, a lot of paid leave, which means that your project could be done slower. There's no I'm not trying to say that the U.S. is best in these categories by any means. I'm just saying these are things to consider, right? When you're making a decision, consider these things. Consider the fact that if you hire an agency out of a country where they work 50 hours a week, then there's a likelihood for quality to go down as burnout goes up.
[David] (17:55 - 19:01)
Yeah. And I would say, you know, this we're making this video from the point of view of business owners who are in the United States. But we might be making these same points if we lived in a different country about not hiring a U.S. firm. Right. Because of the communication challenges, the time zones, the culture, it's really targeted towards people who are experiencing these things, who are here in the United States and they're looking for the best way, you know, to get their project done. And like you said, it's a generalization.
Sometimes you'll find somebody great. I think what really makes the difference and I know we'll talk about some potential solutions in a little bit, but I think it really makes a difference if you can really be selective and find somebody great and then develop a long lasting relationship, whether that's in the United States or outside the United States. That's really what counts is that long lasting relationship where you're developing rapport.
You're starting to understand how the other person works or how their team works. That's really when things start rolling and you're really seeing efficiency in your projects.
[Kelson] (19:02 - 21:46)
Yeah, I agree. That's definitely one of the strategies to improve the quality of your relationship and the quality of the product. Some other strategies might be to have more frequent communication, especially in like a video conference.
You know, there's a lot we've talked a little bit about. We've talked about miscommunications and different languages and that's why having like a really good project management tool and using them to the best of their capabilities can slightly mitigate some of the miscommunication challenges and also make sure that everybody's on the same page. Everything's transparent.
You should set expectations on, you know, how long until I get a response. If I don't get a response by this much time, what happens? There should be pretty strict guidelines on the quality of the code and what's expected.
The code should be audited and reviewed frequently to make sure that low quality code is not going into the application. If you decide to, you know, these are things just in general that mitigate strategies for miscommunication, but the need for these strategies increases when you decide to go offshore. Like the need for more detailed documentation or, you know, some of those cultural nuances, the communication styles and attitudes towards superiors, deadlines, things like that.
Those problems can be mitigated by a more open dialogue where you convey very strongly that, hey, I want to hear about these problems and this is how I want you to communicate with me. Frequent discussions with no agenda can be helpful. If you admit your own mistakes, your own failures can make it more comfortable for them to talk about their own suggestion boxes or some form of being able to submit correspondence anonymously.
And then, you know, several feedback loops in every system, the project management and the development where we're analyzing not only the technical skills, but the soft skills of the individual and providing frequent feedback on those things over and over again can be really helpful to kind of mitigate some of the challenges that we experience in communication. So, yeah, that's just to kind of summarize, I guess. There's a lot of miscommunications and most of them have to do with time zone and cultural differences.
Those are the most challenges that we see. I'm sure there's a bunch of ways to mitigate them. The ways to mitigate them is something that needs to be increased when hiring an offshore team.
But they still need to be implemented even if you hire a U.S.-based team.
[David] (21:46 - 22:26)
Yeah, makes sense. That's a solid list. Yeah, I mean, those are, like you said, good things to practice every time, including, you know, like the project management tools.
I know at Ksense, we're using JIRA and things like that to keep everything organized. Let's talk a little bit more about project management and how that varies. For example, in the U.S., when I talk about business acumen earlier, that's an example, right? We're all really familiar with these project terms and, you know, sprints and project lifestyles and user stories. How do those project management techniques and terminologies vary when you're using offshore teams?
[Kelson] (22:26 - 26:35)
Yeah, it's a lot of what we've already talked about. You know, in terms of communication, agencies in the United States tend to prioritize more real-time communication, phone calls, Slack, Teams, whereas we see a lot of times the trend shows that offshore teams tend to use asynchronous methods, which makes sense, right? But that results in things taking a little bit longer.
And then we have, like, the different communication styles that can result in misunderstandings. I was trying to look into seeing if development methodology that's used by U.S. versus offshore, and it seems like in terms of, like, the methodology for building software, it's kind of all over the place. You know, you can find an agency in the United States that subscribes to a waterfall or Big Bang methodology, and you can find that all over the world as well.
So I couldn't find any convincing data that shows that the project management methodology or the development methodology is much different, and I had a little bit of a difficult time really getting a lot of data in terms of the project management style as well. I can share an anecdote. What I've seen is that usually in terms of the project management, I've had the experience of working with the one person on their team that speaks English, and then all of the requirements are translated into the local language, and that caused a number of headaches because once translated, it was it's hard to explain to somebody who maybe only speaks English.
David and I both speak Spanish, but it's hard to explain the nuances that get lost in translation. There's a million different ways that you can translate something, and some of them are closer than others, and that's why, you know, if you're into religion, there's a lot of debate over different translations, and there's tons of different translations for all the documents, right? Like how many different translations are there of the Bible, and then there's certain groups that say, oh, this translation is closer, oh, this translation, and you know, and they interpret it different ways based on the translations.
That ends up happening with your project requirements, and in my experience, it can be pretty challenging to deal with because what ends up happening, the cycle looks like this. You explain to somebody in English. They repeat it back to you, all the requirements back in English, and then it gets built, but there's just a couple things that just aren't right, and so you ask about that, and they're like, oh, well, you said this, and you're like, oh, okay, and now I see where the miscommunication happened.
All right, let's fix that, and it's just this constant thing, this constant cycle of clarification. Obviously, there's different ways that you can mitigate this, but even through all of the attempts of me mitigating it, which were pretty extensive, I did like detailed documentation, I did mockups. Even with all of that, I wasn't able to get rid of the failed shared understanding, the failure of being able to share the understanding with everybody on the team.
Really, the only way that that's possible, from my experience, is to get on a call, talk about it, and allow everybody to ask questions on the team, and so that's what we do. We have our business analysts get the requirements, and then everybody working on it gets a chance to talk about it and come up with questions and make sure everybody's really aligned, but yeah, that's been my experience, and I'm not saying that that's the experience everybody will find, or perhaps there's people who have an agency and they have really good project managers, but that's been my experience, and the experience of others that I've heard have had similar experiences to me.
[David] (26:35 - 27:36)
It's a common experience. It's something that I hear all the time. People talk to me about the projects that they've outsourced and the struggles that they're having, so I think we're doing a good job of dropping in disclaimers as we go.
We're not trying to hurt anybody's feelings. We're not picking on anybody, but this is a common experience, and we're trying to dig into why. Why does this happen?
Then also, what are the risks? Not only might you have a bad time, but a lot of software projects are important. Typically, we're talking about your company data, your client's data.
We're talking about performing specific functions, and in some cases, the software is doing something really, really important. It could be life-saving. Let's talk about that a little bit, about intellectual property risks, data security risks.
What are some of the risks and what do people need to think about if they're going to be outsourcing a project?
[Kelson] (27:36 - 28:00)
The whole security aspect is a pretty interesting thing to talk about because in the United States, people are very familiar with how strong our contract laws are. I think there's a tendency to assume it's that way all over the world, but as soon as you start to think about it, especially if you think about specific examples like China, you hear about them ripping off our IP all the time.
[Kelson] (28:01 - 30:25)
One of the challenges is controlling the copyright of your application and then enforcing infringements of the copyright. Just go to Google or whatever search engine you're using and look up instances of copyright infringements from other countries, and you'll see very quickly that it's very difficult to enforce it. One thing that is really important if you decide to offshore your project is to make sure you have control and the security protocol in place to mitigate that risk, which can be things that you do.
For example, maybe you keep all your data out of their hands. They never touch the production data or very strict user roles and permissions in the different softwares that they have access to. Maybe they don't have the access to the entire code base.
There's probably other ways you can do it. I'm not a IP lawyer by any means, so maybe there's something you could do in terms of discussing with a lawyer and saying, hey, what can we do to really protect ourselves when we're working with this country? They'll probably be able to point you in a better direction than I will, but that's definitely something I would urge you to do is take into consideration your data privacy and your intellectual property and copyright and make sure these are things you're going to protect.
Obviously, the risk goes up depending on what these are. If the data is incredibly sensitive, then you need even more protocol in place to protect it, whereas in the U.S., a lot of times, depending on what it is, an NDA might get you by. Just a standard confidentiality agreement saying, hey, I'm not going to share this data, that might be all you need.
But again, disclaimer, speak with a lawyer, see what you can do if you decide to go offshore, but definitely it's something worth thinking about and something worth talking about. It's sad to see all of different stories about data leaks and copyright infringement coming out of other countries. I'm sure there's a strong effort by these countries to strengthen their contract laws.
[David] (30:25 - 30:51)
Yeah, I mean, nobody ever thinks it's going to happen to them, right? But especially if you're fishing in a really big pond like this, yeah, you got to know what's out there, and that's a big risk. How do offshore and onshore USA teams compare when it comes to just delivery speed, just getting the project done and being able to scale it up as well?
[Kelson] (30:52 - 34:18)
Yeah, so there's a couple different ways that we talk about scaling. We talk about the scalability of the team, which is how fast can we get new engineers on the team. If we need five new developers, how quickly is it going to take to get those?
And then there's also the scalability in terms of how the software can scale, how many users, how much data can go through it, things like that. So in terms of the team, when we're talking about adding new people to the team, we find that a lot of times in the United States, it might be a little bit slower due to less specialized talent, whereas offshore teams might have more options, especially if they're hiring worldwide. However, one of the caveats is that there is additional challenges that come with the quality and culture of the team and how they interact with each other.
That's something to think about. And in terms of the software, which is more users, more data, faster systems, we see that the United States has an advantage here because a lot of the engineers in the United States have a lot more experience with very high-scale systems, and that's largely due to the amount of large-scale systems we have in the U.S. We have a better understanding of specific challenges when it comes to scaling in the a higher level of expertise in the cloud services that are most popular here. One thing that is something that's interesting is that we see that offshore teams might have more creative solutions for scaling in resource-constrained environments, which basically means how can we get this much data through, how can we get this many users, but we don't have a lot of people to maintain these systems. In the U.S., a lot of times, if we're building a large-scale system or an application that's very large or complex, we also have the money to maintain all those systems, whereas we see that sometimes in other countries they may have less resources at hand, which means that they're forced to innovate. We see that, and it's quite interesting. You asked about delivery speed, and because of some of the challenges that we talked about previously with communication, asynchronous communication styles, things like that, we see that offshore teams are a little bit slower to ramp up and get started, and then a lot of times the development cycles, we call them sprints, how frequently are you getting working software in your hands or how frequently are deliverables being completed, seems to be a little bit slower. In the United States, prioritizing real-time communication, which was phone calls and Slack, Zoom, things like that, along with the cultural alignment, less misunderstandings, we see a quicker ramp-up time and overall faster development cycles. So there's kind of a little bit of information about delivery and scalability, both with teams and software.
[David] (34:19 - 34:30)
So what are the long-term implications of one or the other, whether you choose an offshore team or an onshore team? As time goes on, what does that look like?
[Kelson] (34:31 - 37:43)
So there's a lot of long-term implications. You were talking earlier about a long-term relationship, right? That's important to talk about because a lot of times it's easier to establish a relationship with somebody in your same culture, with somebody that has shared understandings, they grew up in a similar environment to you.
So there's kind of a higher level of cultural alignment if you're from the United States, and it's a lot of times more simple for you to create and maintain relationships because of this. So we see that that tends to be a benefit in the long-term for these types of applications. We also see that in the United States, due to lower turnover, teams tend to have a higher level of institutional knowledge.
What that means is they're more familiar with the code base, they're more familiar with how your business operates, they're more familiar with the stakeholders, their pain points, and the solutions to solve those pain points. We talked about some of the challenges, some of the miscommunications, some of the nuances. Those have a lot to play with the offshore teams in terms of the long-term repercussions.
I was briefly telling everybody about my experience with those cycles that I had where there's a thing here or two that was miscommunicated. What ended up resulting of that is a lot of extra development hours, a lot more back and forth, and a lot more of my personal time spent trying to iron out all the wrinkles. So that's something that's really important to consider when you're trying to plan for the future.
Things to expect, things to prepare for, some of the implications in terms of offshore might mean that you need a lot more of a lot more mitigation strategy in place for all of these risks. You might need better project management tools, you might need to spend more time working with the team, you might need to have more documentation, more lawyer fees for protecting your data, protecting your copyright, things like that. So yeah, it's really important to consider these long-term implications because a lot of times people think that the project is kind of a one-and-done or that, yeah, this is a three-month-long project.
In my experience, projects end up going longer than you think usually and they almost always turn into long-term things even after the software is completely done. You still need somebody to go in and maintain it, somebody to update it, backups, whoever you choose to do the development work. A lot of times it's a long-term decision, it's a partnership.
It's really difficult to take the app out of one team and put it into another and if you do that, it ends up costing a lot of money because they have to learn everything from zero. The new team has to learn about all your stakeholders, they got to learn the code base, everything. They got to learn how to work with you even.
So it is really important and so hopefully I laid out some of the things to consider, some of the implications here.
[David] (37:43 - 38:19)
Yeah, I think so. That combined with my anecdote earlier about that contractor for a simple internal task, it's got me thinking about how often do these things fail? I know that there are projects that we've taken on before where somebody had already started development and then they needed somebody to actually come in and clean it up and finish it up.
So what are the success rates like for offshore teams versus teams in the U.S.? So there's a couple of studies that we can look at.
[Kelson] (38:19 - 39:47)
There's a study that was taken in 2016, that's the McKinsey & Company study and the key points of that study show that 50% of offshore projects fail to meet their objectives compared to around 30% failure for onshore projects. And then there's a PMI, which is the Project Management Institute study that came out in 2021 called the Pulse of the Profession and it says that organizations with mostly slash all onshore projects, 77% project success rate, whereas organizations with significant offshore components, 65% project success rates. So the data shows that the project is about 15 to 20% more likely to meet its objectives, which I would translate to be successful if that project is handled onshore, which in our case onshore means we're in the U.S. so onshore means in the United States. Now the risks, your percentage might vary, right? Your organization could have 100% project success with offshore. It really depends on how well you mitigate all of the risks and how well you manage the project.
[David] (39:48 - 40:05)
So what kind of advice would you give people who are making this decision? I know we've talked through a lot of the challenges, but if you could just give let's say a business owner or an executive some general advice as they're going through this decision making process, what would you tell them?
[Kelson] (40:06 - 43:51)
I think that it's important to really truly understand your project, what's involved, how well defined it is, how complex it is, what type of data are you going to be storing, is it going to be highly sensitive data, how important is it that your intellectual property is protected. That's something, if you're able to answer all of those questions, it really can help you point in the right direction because if your project is not complex at all and there's really low risk, then it might make sense to choose a more cost-effective option. Speaking of cost-effective option, another thing is to really evaluate your budget.
How much money are you willing to spend on the application? And when you're thinking about the costs, don't think about the hourly or salary costs. Think about the total cost of ownership.
Factor in the fact that if you decide to go with an agency where nobody speaks your language or very few speak your language, then there might be additional cost on you having to reiterate or clarify. You need to consider the cost of going back, you need to consider the cost of perhaps being on more of an antiquated solution or technology. You need to think about the cost of getting the project to market that may take longer offshore than here in the United States.
You need to think about how quickly you need the app done. In the United States, we tend to see applications being built more quickly. So if the project is more urgent, then that's another thing that could point you towards choosing the United States.
And if you have more time, then you might accept the cost savings. Think about your business. Is your business especially going to be difficult for somebody in a different country to understand?
This is really important for systems that revolve around practices that mostly happen in the United States. An example that I can think of off the top of my head is finance. Our tax system is very unique to the United States.
And a lot of our healthcare processes are probably also. I'm no expert in that though. But evaluate the cultural fit.
Think, hey, is this something that's going to be really hard for somebody that didn't grow up in this culture to understand? Government contracting applications would be another really good example, which would be applications that help people find government contracts in the United States. Find an agency that has the most experience with the demands of your application.
If you need an application that can scale to 100 million users or something ridiculous, then find an agency that has experience with that, regardless of where they're at. I think it's important, regardless of what you decide to talk with a bunch of different agencies, regardless of the location, and asking them how they overcome these challenges. Because these challenges of communication and misunderstandings and culture, they're not unique to offshore.
These are things that happen here in the United States. Just because we all speak English doesn't mean we don't miscommunicate project requirements. So ask the companies how they handle these.
And then write those down and compare all of them to get to each other. And that'll help you in making the most well-formed decision that you can.
[David] (43:51 - 44:57)
So if I were to summarize a little bit of what my takeaways are from this conversation, it sounds like, again, there are great people everywhere, lots of great talent out there. If you are handling a project that's maybe time-sensitive or it really matters to keep your data secure and your intellectual property secure, then there are a lot of reasons to stay within the United States. If your priorities are more on budget, and maybe it wouldn't really hurt you very much if this information got out, or if the project takes three or five times longer than you expected, then it might totally be worth the cost savings of going with an offshore development team.
Either way, there's going to be challenges, but most of those challenges are easier to address with an onshore team that you can communicate well with and you can understand each other and the project requirements. So what do you think of my summary? Is that accurate?
[Kelson] (44:57 - 45:43)
Yeah, I think that's probably pretty accurate. I might also say that when it comes to cost savings when you decide to go offshore, another thing is if you're willing to put in all of the effort that it takes to mitigate all those risks, then it really could be worth it. I acknowledge the bias in my personal anecdotes, but I've heard stories of people building really good offshore teams, but usually the way that they get there is through a lot of effort of their own.
So that's something to add into the summary here, is that if you're willing to put in a ton of effort and mitigate all these challenges, then it really could be worth it and you could save a lot of money.
[David] (45:44 - 45:45)
Makes sense.
[Kelson] (45:45 - 46:17)
If you don't have the time because you're running your own business, then as we stated at the beginning of the call, you're really only saving 10 to 15%. Is paying 10 to 15% more worth the savings, your time savings really? Or are you willing to put in the effort to save 10 to 15%?
So that's really the question that needs to be asked, I think, when you're trying to make the decision and it's a personal decision. Each business is going to have to evaluate their own needs.
[David] (46:18 - 46:24)
Awesome. Well, thanks so much for joining me today, Kelson. I think that was a lot of value-packed information.
Hopefully people out there find it helpful.
[Kelson] (46:26 - 46:33)
Yeah. And if anybody has any questions, feel free to leave a comment and we look at them and we'll answer any of them. So cool.
Thanks, David. Thanks.