From Softjourn's CEO

A complaint we often hear from those who have sent work offshore is, Why didn’t they just ask questions if they didn’t understand? There could be several reasons for this and one of those could have been underway from the very beginning of the relationship. From the first encounter with your potential partner it helps greatly to set the appropriate environment for asking and answering questions has been set. I know I get quite a few RFP’s (Requests for Proposal) from companies asking me just to send back a proposal with timeline and cost and not allowing for any time to ask any clarifying questions. Many companies seem to want to do this because they want to just get a quick price quote from many companies for quick comparison. If that is all you want and are not seriously looking for an offshore partner, you won’t be harmed by not allowing for questions. But if you really want them to build something for you, and you want to make sure they know what they are doing, then allowing them to ask questions of you in real time and receive answers will set the environment for asking questions throughout the entire project and time you are working together.

On the same vein, if you do give your potential offshore partners the opportunity to talk with you in real time, to ask questions and for you to ask questions, if they do not take you up on this offer, I would be very worried. If they can give a price, especially if they are giving a fixed bid price, without asking any questions, you may have cause for concern. Specifications, no matter how well written are subject to interpretation; two people reading the same thing, even if they come from the same background, can easily glean two different visions of what needs to be done.

Another fallout from not setting the right stage from the very beginning, and another reason you may not be getting exactly what you want; when you start out your offshore project with just a quick bid and proposal, you may have inadvertently given your offshore partner free reign to interpret the specifications per their discretion. If that is what you want okay then be prepared that you may not get exactly what you want. This includes both from a functionality view as well as technically (i.e. they may not have used the right technologies to develop your solution, if these were not clarified up front. If it doesn’t matter to you, that is okay, but if it does matter you would rather find out sooner rather than later.).

Interaction is usually required to make sure that all parties are thinking along the same lines and it is best if that interaction starts from the very beginning, before even choosing an offshore partner.

Picking the right project is actually part of a bigger question; pick the right project to undertake in the first place. It has as much to do with asking the question whether the project should be undertaken at all, as to whether or not it should be done offshore. Can an ROI be calculated for the project? Will the project be adding a feature that clients are asking for, etc? It is a good idea to ask these questions for two reasons. The first reason is that it forces you to think through the entire project and secondly it will assist in assessing whether or not you got what you were expecting once the project is over. For example after completion and implementation of the project, what is the actual ROI for the project?

Another rule to follow when picking a project to offshore includes picking the right first project. If you are new to offshoring, or if you are working with a new offshore partner, it best not to pick a project, which has a tight deadline, i.e. one that must be in the customer’s hands in six weeks and it is a five week project. You may be setting yourselves up to fail. If this is your offshore project, your in-house team will certainly have a learning curve, and if it is your first time working with a new offshore partner, they will also need some ramp up time.

The guidelines for picking the right project to offshore should follow very much the guidelines your company uses to determine whether or not to undertake a project in the first place, and whether or not to undertake a project with a new team or with an experienced team.

The best practices I am going to go over are centered on three areas parts of offshoring; getting started and the transition phase, the process of offshoring, and the results.

Best Practice #1: Don’t write a huge requirements document.

One typical difficulty we often hear is that it takes too long to define the necessary requirements for an offshore project. Part of this may be due to a misconception that the best and most creative code is written by having five guys sit around and just start coding, but if they have to write something down they lose their creativity. On the contrary defining what you are planning on developing, using words or conceptual definition forces a person to think through what needs to get done. It is easier to see where there are holes, where something has yet to be defined. So having gotten over the hurdle of whether a product definition has to be written down or not, then the question is, How detailed does that document need to be?

For the most part, you can safely assume that the members of the offshore team that you deal with are thinking people. They do not need to be told exactly what to do, i.e. code this statement here, this statement like this, etc. You should find that you can work with your offshore team in a manner similar to what you would do if you were all in one location, i.e. everyone reads the specifications as written, prepares questions, and you walk through the specifications by phone, also using collaboration tools to share diagrams or document changes as you are going through everything. It should not be necessary to write a 100,000 page document before getting started, sometimes just thinking that you must write a huge document, and about how much work it will be do write that document, often paralyzes companies from getting started offshoring.