By David Ortiz

Offshore development: two words that many people cringe when they hear. Hey it’s fine to admit it, we all have our ideas of what offshore development means. Right off the bat we think cheap development while sacrificing quality, but boy was I wrong. Luckily for everyone, I’m not too proud to admit when I’m wrong, and in this case I learned that offshore development, when managed properly, can not only be effective but an asset that can take your IT staff to another level. The key there is the phrase “managed properly.” We need to understand that offshore development is not the same as a typical development team and we need to focus on three key items to be successful. First and foremost, we need to go into this endeavor with an open mind. Second, we need to create very detailed requirements documentation. Lastly, we need to have a well-defined methodology around logging issues.

So having an open mind… what does that mean? It’s simple: many times offshore development is doomed from the start because onshore staff is skeptical of the idea to begin with. They have the attitude that it will never work or they fear the idea that offshore will eventually replace them. The reality is this: if you’re worried about your job security with offshore dev, then you have far bigger issues than what will happen with the offshore team, so let’s squash that right there. However, the flip side can be great if we embrace the idea of what they can bring to the table, we could eventually have a team that can develop round the clock to support the ever growing needs of business units.

The fact that I have to point out that we need detailed requirement docs is more of an indictment of how poorly this is done to begin with. Unfortunately, I’ve worked on far too many projects where this work stream has been overlooked or better yet oversimplified. Requirements gathering has to be the MOST important part of your project, especially when working with offshore teams. We need to understand that with offshore dev, you’re not going to have the luxury of dev teams running to business analyst or the business units themselves to clarify items or get more detail. This mean it’s imperative that our BA’s and even tech leads document the requirements in a way that a developer can read it and get to work. Let’s get something clear: this should be the case in any project, however I will reiterate this is a necessity when working with offshore. The better you document the more successful you will be.

Now that we’ve opened our minds to the idea of this offshore team and we’ve documented our requirements in wonderful detail, we get to the fun part DEVELOPMENT…. I know I know our requirements doc is so wonderful that we won’t have any issues to log, however just indulge me here for a couple more minutes. The need to log issues is key when working with the offshore teams. The fact is your hours are going to be vastly different: your morning their night, their night your morning… it’s crazy, confusing yeah I know all the excuses. So communication is very important and this where issues logging comes in to play. You MUST have some centralized location where offshore dev can log issues and in turn onshore tech leads or BA’s can reply with answers. It can be something as simple as an Excel sheet that is stored on SharePoint. I’m actually in the middle of a big BI project for a telecom company and my entire dev team is offshore. Our issues logging is very simple. My developers have an Excel sheet where they log all their issues, they update the sheet every day at the end of their workday. First thing in the morning I grab the sheet and update with any answers that may be needed on open issues. This sounds so simple but it WORKS.  Not only do we have a central place where we are logging our issues, but we’re also creating accountability on the project.

So there you have it, three simple things that can make your life a lot easier when you’re introducing offshore development into your environment. It’s funny I was always against the idea, mainly because I didn’t trust the unknown, but now that I have a full team offshore working on all of our BI projects, I wouldn’t have it any other way. Not only have I been impressed by the quality of their work, but I’ve been more impressed with the quality of the people.