Jarosław Granat (JG): Hello and welcome to IT Leadership Insights by Future Processing. My name is Jarosław Granat and my guest today is Ross Morrell Director of Target Services, a UK based consultancy. Hello Ross and thank you for joining us.

Ross Morrell (RM): Thank you for asking me.

JG: Ross the last time we spoke together was about the differences between offshoring and nearshoring. And today I would like to delve deeper into the cost connected to that. And I know that you’ve helped a lot of companies in their IT strategy. And part of the strategy is always talking about the cost connected to that. So if you could just tell us what are the differences, what are the costs connected to IT projects when it comes to onshoring and neashoring?

RM: Yeah, so I’ve actually been on both sides of that equation, I’ve been helping clients to make selections and differentiate between different options. And I’ve been actually a supplier being selected. So I can say from my experience, I’ve seen a number of different approaches. At a simple level what I would say is that first of all you’ve got to make sure you’re comparing apples with apples, if you like. I’ve been in meetings where it’s been as simple as a an executive picking up a rate card, comparing the cost of a developer to the wages he pays his own developers and making a decision based on that. What I would say very simply is it’s like an iceberg and there’s far more to consider than just those top level numbers.

JG: So is it any way to compare the salaries of a permanent person to a rate card from a supplier?

RM: Well, if you’re building a business case, I mean, assuming that you’re trying to decide between in-house and, say, nearshore obviously, and I am stating the obvious, you’re not using just a wage number that you make the comparison on, but the fully-loaded cost of your employee. So, this includes all the taxes, the pensions and benefits that you’re paying them. And you know, most people understand that but don’t always use it. I would say that the numbers I’ve heard mentioned in the UK typically are anything from 1.25 to 1.85, and probably in London, more like 2 where you take the salary and multiply it by that factor. But equally, it’s true that to be making a fair comparison, you’ve got to look at the cost that might be incurred by outsourcing to a nearshore partner. So for example, the cost of travel, which in turn is determined by how much governance you need to apply in terms of the relationship with that supplier. Perhaps there’s your own in house costs of having your own people involved in the project, including the cost of onboarding and passing on information. But maybe even overtime costs if you’re looking at the differences between different working days. So all of these need to be thought about when you’re making comparisons.

JG: But still, it’s some kind of a basic comparison, I would say. I believe that there are, let’s say, non-obvious or hidden measures that tell us something about the total cost as well.

RM: Yeah, well, again, from my experience, I mean, some people just focus in on building clever models, literally done by accountants, which compare these headline numbers and even with those extra costs in, I still think it’s not always easy to make that choice. And the reason I say that is there are a number of soft factors that I think need to be very carefully considered such as productivity. When you’re comparing a developer in-house or offshore, or nearshore, then quite obviously you have to take into account how quickly and how efficiently that person will code. And there are definitely differences in terms of the quality that they code. So quality and productivity both have impacts on the real cost of your project. And along with something that is even softer, which is what I’ve called ‘relationship dynamics’, fully integrated and motivated teams get work done better and quicker, in my opinion, than any other type of environment. So it’s important to understand how you’re going to work together and what the perhaps hidden costs of that might be.

JG: So how to make a choice then because I can imagine that the company who needs to find a supplier, make a choice, visits the company, goes through the RFI processes, has all the measures numbers, etc. But it may be not taking into account all the things that you said about the productivity and other so how does a company make a proper choice?

RM: I think absolutely. And I think even more so in this much more digital sort of joined-up world where things are moving much more quickly and projects are often run on an agile basis. I think some of these traditional matrix- based ways of choosing are probably quite inefficient. What we’ve seen work really well is to find a shortlisted supplier and work with them on a prototype or a pilot project. And in that way, these sort of hidden costs, like the productivity. Productivity is impacted, for example, by their comprehension, do they understand what they’re trying to do, you’ll learn that very quickly in a pilot project. It’s also affected by therefore the quality that leads them to produce. So you can start to make some assessments on how much you need to put into your model for the likelihood of bugs coming out of the work they do. And finally this relationship dynamic is only tested when you’re working with them.

JG: So if I understood you correctly, you would advise your clients to become a part of the project and give it to several companies just to make the pilot project and to see the results in a short amount of time in order to not invest a lot of effort and money probably in the beginning?

RM: You can do that if you wish or you can use your traditional methods to find the one that you think is the most suited. But then don’t be afraid to test some of these softer issues by running a pilot project with them before you commit.

JG: Okay, I got it. Thank you Ross for this advice and thank you for being here and talking with us.

RM: Thank you.

JG: And thank you the viewers for watching this episode of IT Leadership Insights by Future Processing. If you liked it, please share it and recommend it and if you would like us to talk about other topics, just let us know. Once again thank you and see you next time.