From Softjourn's CEO

A common complaint from managers of offshore teams is lack of communications. Either the team never gets back to them when they are expecting an answer, or they can’t find the team members when they need assistance or they have an issue they want to work through, etc. Usually a lot of care is taken in choosing who will work on a team. As much care should be taken in deciding what will be discussed during the meeting, how you will communicate with the team, and when communications will take place. The what is the type of meeting to take place; status meeting, design meeting, steering committee meeting, etc. The type of meeting determines how the meeting should take place, what means should be used for the meeting; is a conference call enough, do we need to use a collaboration tool which allows sharing of a desktop or a whiteboard, or will video or web conferencing work better to discuss and make the decisions that are necessary during the meeting. The when is obviously how often the meetings will take place. It is best to if at all possible make it convenient for both sides. This will depend greatly on the number of hours difference between the two or more locations. If up to twelve hours difference consistently having meetings at 7:00am for one side and 7:00pm for the other side is usually not too much of a problem. If the number of hour’s difference is more than that, it is best to vary the times of meetings so that one side is inconvenienced during one week the other side the next week. In the end it depends on what both sides agree on and what they are comfortable with. The most important thing is to have a schedule of the meetings, what will be discussed and by what means communication will take place, and make this schedule available to all. If a project site is used by the team; which one should be used!, the schedule should be on that site.

Thus far I have not mentioned emergency situations. First, as a manager of an offshore team, you have to think what constitutes an emergency situation. If your project requires around the clock support (for example if the system is already in production), that is another type of communications to cover off-hours that I will not discuss here. But occasionally something may come up during the work day of one party where they need to get in touch with someone in the offshore location to answer a quick question or to talk over something. Therefore each party should discuss and document how these questions will be handled. The easiest thing of course is to make sure that mobile phone numbers of all parties are available; again another good thing to document on the project site of the team. If for example you are worried about the cost of mobile calls from the US to the offshore location, for example, check out a service like; www.fring.com, which enables the receipt of mobile phone calls via Skype or GoogleTalk, etc.

In the end, daily communications works the best, in this way you are never left wondering, will they be around tomorrow when I really need to talk with them, or will we have time to go over what we need to go over. If there is not much to talk about during a daily status meeting, then the meeting will be really short, but if there are questions and issues to discuss you know there will be an opportunity to solve them. Also by establishing a daily time for meeting, it is much much easier to cancel a daily meeting if something comes up than it is to pull one together at the last minute when is needed in an emergency.

Often companies or managers feel frustrated when offshoring, feeling like they have to spend so much more of their time explaining what they want, or having to explain what they feel are very simple things.

Sometimes it certainly can feel that way, but perhaps it is time to look at how this can be turned around. It is better to explain the concept of what you are trying to accomplish, what the end result should be and be open to input from the offshore side as to how that outcome can be accomplished, as opposed to explaining exactly every single detail of how something should work. In addition to getting early buy in from the offshore side, this can also open up your company to new ideas and perhaps give you an edge over your competition. Because of how business is done in developing countries; retail transactions, banking transactions, etc., may be taking place in different ways that may be beneficial to your product or service. You may be able to adapt new processes; so don’t look at it as something extra that you have to do, but think of how you may benefit.

In the cases where the users of your software must absolutely work in a specific way, for example, in procedures that are highly regulated, be sure to explain the why behind what the users are doing. Why they must perform their functions in x, y, z order and no other way.

Another outcome that should be shared with the offshore team is the Return on Investment (ROI) you expect to achieve by undertaking the proposed project. Contrary to popular belief most developers want to know that there is a business reason behind the project that they are going to be working on. It helps them understand the bigger picture of the project, why the project is important for the company (or client if outsourcing), and why they need to work on it.

As always, at the end of any project, include in the post mortem the actual results achieved; how the users like the end product, and how close to the expected ROI the project came.

Some time ago I started a list of the 9 Best Practices for eliminating the typical difficulites that are associated with offshoring. Now I would like to get back to that list.

Before I do, here is a recap of the first four best practices.

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.

Best Practice #2: Pick the right project to get your feet wet offshoring

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.

Best Practice #3: Set the stage for questions and answers when offshoring 

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 RFPs (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.

Best Practice #4: Don’t be afraid to get the answers you need when offshoring! 

It’s your software that they are writing, don’t be afraid to ask questions, and don’t be afraid to engage in working sessions the same as you would if your team was in-house, to find out how they plan to do something. If the technologies your offshore partner plans to use will affect the rest of your solution, be sure to engage in a conversation so they can explain their technical solution to you, and you can ask questions.

Throwing a project over the wall and waiting until something comes back, increases the chances that you won’t be happy with the results. You may hear outsourcing experts state that you have to manage the process. You do not necessarily have to manage the process in that you have to set the timeline, or check with their status everyday, if your partner is managing the work as a project. However, you will want to have periodic checkpoints where you see what has been accomplished thus far and where you can ask why something is being done in a certain way, etc.