By Leonardo Mattiazzi, VP International Business, Ci&T

I’d like to discuss a topic that often comes up in deciding whether to outsource to an offshore or nearshore provider – location.  Specifically, I’d like to challenge the notion that location doesn’t matter.

Today’s digital infrastructure is sufficiently solid in the entire developed world and in most emerging countries as well.  Technical skills are abundant in many different places. There’s no physical good to be transported, and telecommunication technology connects people virtually everywhere.  Since software development is a knowledge-based activity, it can be performed at any place where the knowledge worker is, right?

It’s no surprise that Thomas Friedman got his ‘aha moment’ that inspired him to write “The World is Flat” when visiting an executive from an offshore outsourcer.  This company built processes to facilitate globally-distributed work and make them as seamless as possible.  They invested in certifications that proved these processes to be mature, and therefore more likely to be successful.  They have clients in every corner of the planet, and serve them from their central hub in India.  And their processes proved to be so superior to those of local competitors that these processes achieved the “best-in-class” status and were emulated around the world.

This is all true.  But there’s another critical truth missing from this puzzle.  Software development is a team activity, and it’s crucial that the client is part of that team. The client is the primary and indispensable source of knowledge in defining what must be developed, answering questions related to the business and some related to technology, providing feedback on what is being produced and accepting the quality of the deliverables.

Is this possible when the client is in one place and the development team in another? For the most part, yes, for the reasons listed above.  Unless you want to have everyone (including vendors) co-located in the same building (and pay the price for the infrastructure), even if you partner with local providers, the team will be somewhat distributed.  You’ll use teleconferencing, web conferencing, instant messaging and other tools even if your partner is across town.  So, what does it matter if the person on the other end of the line is in the city, in the country, in the continent or even in the planet?  Not so much, and in that sense the world does seem pretty flat.

Let’s continue with the assumption that it doesn’t matter where the knowledge workers (the development team) are.  You’re using teleconferencing, videoconferencing, web conferencing, instant messaging, screen-sharing and all sorts of tools, all running on the powerful Internet backbone, right?  Information back-and-forth with a snap of our fingers, all connected, instantly, anywhere.  And with our devices, iPhones, iPads or iWork-All-The-Time, nothing can escape us.  Terrific!

But here’s the critical question:  do you answer emails while you sleep?  It would be a nice oneiric capability, but so far I haven’t met anybody that does this.  So, what if I email you while you’re asleep, asking an important question that’s preventing me from moving forward with my work?  Perhaps I don’t want to wake you up in the middle of the night, so I’ll have to wait until you find my email on your inbox – the next morning – and respond to it.

Yes, but what if when you respond to my email it’s my turn to sleep?  It’ll take another 12 hours for me to continue.  And what if your answer actually doesn’t actually resolve the issue?   Another email might do it, but darn, as soon as I email you you’re sleeping again.  The cycle repeats itself, and nothing gets done.

That’s the problem when there’s little or no overlap of working hours.

But wait a second – we just need to put somebody on-site, a liaison that connects both worlds, right?  We already have a local leadership team anyway, since the client (and the vendor for that matter) needs to have the safety net of face-to-face relationships.  So, can’t we just use that team (maybe with a few additions)?  Yes, and that’s the model that you, me, and everyone in the IT world know.  And what about figuring out how the liaison communicates with the rest of team?  Well, that’s their problem.  The thing that really matters is that you won’t have to wake up at night.  Yes, but is that so?

Now, for a moment, forget about software development, and think what happens when you tell something to a friend, and that friend tells it to his friend, who passes it along to her friend.  Ever play the game “telephone?”

This is an extreme case, of course.  In order to make this model work, so that it doesn’t matter where the development team is, we just need to have a sound process to capture information at the source (through the liaison), document it and pass it along to the remote team.  And if we have people that do this really well, it could even become an advantage over the guys that “just do it”.

So let’s get ourselves a requirements analyst (if she has worked in the same industry for a few years we can even call her a business analyst – that’s cool stuff!), make sure she writes well, make sure the client signs off on what she’s written, and we’re fine.  We’ll establish specialization of work (you think a developer can write these documents?), templates to guide the work, a governance model with clear responsibilities and the rites to get all that done.

Good.  First part of the puzzle is complete.  Now, how does the remote team communicate back to the client?  Well, the reverse process should work just as well.  So the specialists on the team write documents (architectural view, technical specifications, etc.) of how the system will look like once developed, hand these off to the liaison (with some knowledge transfer in between, of course), and the client will be able to have a beautiful overall picture, and will be able to sign off on that. And of course, all this flow is specified in the process, so it won’t fail.

Ah, but then the development advances and the business stakeholders realize that some changes are needed.  Big deal?  Well, we just need to go through the cycle again – capture the change, verify the documentation already produced and verify the impact (by the way, there are tools for that, don’t worry), communicate to the team, perhaps negotiate with the project sponsor a new timeline and some extra cost.  Or perhaps the architecture needs to be modified to consider a new integration.

You know the drill, I don’t need to describe it. But to deal with this complex cycle we as an industry have invested a lot of money in standardizing the software development processes and in a certification (CMMI) to demonstrate that we’re mature and can do it every time, haven’t we?  This process is so superior that even local players now have to follow it or they’re not considered “world-class”.

Because the client is sleeping while we are working, he will get the work done when he wakes up, and we can claim we are more efficient than local providers!

Here’s how I see it playing out…

-------------------

The Truths and Lies of Near and Far - Act I

A vendor connects with his client once the client is awake…

Client:  “Wait a moment, something smells fishy.  Yes, the work was done while I was asleep, but now that I’m awake, is there anybody working on the next step?”

Vendor (embarrassed); “Oh, well, we thought you wouldn’t catch that.  Sorry.  But the liaison team is working, and they said they are talking to you to get more information.

Client (not convinced):  Hmm…

Vendor:  And because we have everything so well documented, you, the client, can go about your “real” work without worrying with the development!

Conversation pauses, curtains close.

-----------------------

Apparently the business sponsors don’t seem to be pleased with the end results that often – at least, that’s what the stats show (I’m sure you’ve seen them). Timelines seem to be longer than needed, and total cost seems to be high, despite the low rates. What the heck is going on?

The world may be flat in some respects, but it’s not quite as flat as Mr. Friedman thinks.

 Nearshore Executive Alliance (NEA) is a new organization established by a broad selection of Nearshore industry leaders and business executives from across the Americas. This group will endeavor to collaborate with each other to increase the use of Nearshore. NEA will contribute to the overall benefit of the Nearshoring industry by enabling collaboration with industry thought leaders, sharing of location intelligence and best practices and provide market/media education.