Onshore-Offshore model is a very common Global Delivery Model adopted by almost all major organizations across all industry horizontals.

What?

Dictionary Definition of OFFSHORE:

ˌôfˈSHôr,ˌäfˈSHôr/

adjective & adverb made, situated, or conducting business abroad, especially in order to take advantage of lower costs or less stringent regulation.

verb

relocate (a business or department) to a foreign country to take advantage of lower costs.

Why?

Incentives for engaging an offshore team:

Cost saving, increased productivity, meeting core competencies, expertise and skills, on demand (24X7), at short notice and without long term commitments.

Why Not?

Major hurdles in engaging an offshore team:

Time difference, language, cultural barrier, quality of deliverables, lack of control, turnaround time and security risks.

In this post, I want to be neutral and want to make clear that neither am I a proponent of offshore model nor an opponent. Let’s debate the pros and cons in some other post some other day.. 🙂

Recently while discussing with one of my onsite client, I came to know that clients here are not completely aware of how offshore functions. They believe that after they give the business requirement, their responsibilities are over. In short, offshore model is a Black Box to them. They are only interested in the final deliverables and not in how offshore get the things done.

I have worked in the onshore/offshore model for conituous 8 years and in both sides (onsite/offsite). I can say, I have tasted the sweetness and bitterness of both zones. I have fairly good understanding of the model, its advantages and bottlenecks, the pain points and the gain points. This page would give a bird’s eye view to the offshore delivery model so that onshore client’s can have a better understanding of “How thing are done”.

Client’s should understand that offshore team members are normal people with flesh and blood. They have family, friends and social lifes, just like all of us. They are not robots or superhumans. Although, the offshore vendors/managers sell you terms like 24X7 support / response, but those vendors and managers are not the ones working 24X7. The real heroes are the developers at ground zero. If your vendor has a contract for 24X7 response and support, be rest assured, it would be honoured. A part of the staff (developers) would always be working round the clock for you.

Please refer to the flow chart diagram below. In every onshore-offshore model, there is an onsite manager and/or co-coordinator, who is the face of the offshore team. Onsite co-coordinator has the most important role to play. The success of the offshore model is highly dependent on the attitude and aptitude of the onsite coordinator. I stress, right attitude and right aptitude amalgam. Deficiency in any one trait means extra burden to poor offshore team to fill it up (and in practical scenario, every other offshore team has to do it). Onsite coordinator also has to be a good listener and even a better interpreter. One of the major hiccups in offshore model is loss of information during communication with offshore. Information lost is directly proportional to poor deliverable.

Whenever the client’s business identifies a GAP and proposes the solution, they create a requirement document, popularly called as Functional Specification (FS) or Functional Design Document (FDD). If you are working in an onshore/offshore model, better the quality of FS/FDD, better would be the deliverables from the offshore team.

Step 1:

After the FS/FDD reaches the offshore team, via the onsite co-ordinator, the offshore team go through it multiple times. They try to argue/counter argue to get a holistic picture of the requirement.

Step 2:

Once they get the background of the requirement, they get in a call/screens sharing session with their on-site coordinator. They put forward their understanding and questions if any. The onsite coordinator is supposed to clarify everything and if he is not sure, he/she is expected to get back to business owner at client site and send the right clarification back to offshore team.

Step 3:

Based on the complexity and scenarios of the requirement, offshore team provide the most competitive effort estimation and delivery dates. Typical dates are: initial technical design document delivery date, interim code review date, final quality review date and final delivery date to onshore.

Step 4:

Before the offshore developer actually starts programming, he should deliver a high level initial Technical Specification(TS) or Technical Design Document (TDD) to onsite coordinator. This document is expected to have the high level design flow and pseudo codes along with the unit test plan. This is a first step to catch any mis-understanding by the offshore developer. Onsite coordinator should diligently go through the documents and immediately raise a flag if he sees any anomaly.

Step 5:

Development and programming begins.

Step 6:

On a predefined date, mid/interim code review is done. This is a pro-active step taken by offshore team to catch/identify an issue in the design before it becomes a monster during final delivery.

Step 7:

Development is in full swing now. Offshore team might get in touch with onsite coordinator to clarify certain questions (if any). Functional teams help is also taken to get test data. After the development is complete and unit testing done by the developer, he/she documents everything in the TS/TDD. This TS/TDD would be detailed one and a version up. Proof of unit testing is also embedded in the TS/TDD as actual screenshots with working data. Peer review of the development is done so that a fresh set of eyes and mind go through the development and try to identify possible issues.

Step 8:

It’s time for the final review. A senior member from the team or a subject matter expert(SME) from the Quality Review Pool comes for the review. He/She grills the developers with Why, Why not, Ifs, Buts etc questions. No one is perfect. It is customary to get some points in every review session. The SME documents the review points and gives the developer additional time to make the correction.

Step 9:

Developer works on implementing the corrections and suggestions given by the SME. After he is sure that all the changes were implemented, the reviewer comes again and checks the development one more time and if everything is satisfactory, he signs off the review process.

Step 10:

The code bundle and the technical documents are uploaded in the target shared repository and also sent to the onsite coordinator. Now it is the responsibilty of the onsite coordinator to review and test it at his/her end and deliver it to the client.

This is the simplest offshore model for development work in IT industry. In between there might be some custom steps specific to some team in some particular organization. But overall, the above 10 steps are followed in almost all industries.

[adToAppearHere]

Food for Thought

Que 1. But, even after two rounds of review at offshore and one done by onsite coordinators, still clients come back with defects and missing functionality. Why? How can this be minimized if not zeroed out?

1. Whenever the defect is reported, the developer is the soft target and every finger points at him. But in reality, it is the offshore Lead and the onsite coordinator who should accept the responsibility. In the above flow diagram, I have marked steps 2, 4 and 10 with stars. I believe, these are the discrete points where the onsite co-ordinator should be pro-active. He/She should have the complete understanding of the requirements and design. Those information should be passed to the developer in detail and in simplified terms so that there is minimum hiccups at the developer’s end. Many good onsite coordinators send additional document, popularly known has DOU (Document of Understanding) for the offshore team along with the FDD. DOU is a small document prepared by the onsite coordinator which is more technical and has the detailed steps and points where developer should be careful. It has the complete design in nutshell and in the language which the offshore developer understands.

2. Second place where the onsite coordinator can catch possible future issue is at step 4. When the offshore team deliver the initial TDD, the onsite coordinator should review it thoroughly. If the starting assumption is wrong, then definitely the final product would be incorrect. Many times, onsite coordinators do not give importance to the initial TDD and end up doing the rework which means extra time and resource wasted.

3. The third check point is when the onsite coordinator receives the final code bundle and documents. Good onsite coordinators go through the documents and the programs. He/She would even do some sanity check and test the product at his end. Since onsite coordinator is the only member in the team who is expected to know all the functionality, he/she is the right person to break the code and identify the issues which developer might have miss. Only if he/she is satisfied, it should be delivered to the client. But, all co-ordinators do not do that. They directly submit it to the client and there is a risk of escalation. Almost all clients are OK with one day delay in the product, but they do not want a defective product in time. For quality purpose, if the onsite coordinator had to do some changes and which might take an extra day, he should take the client into confidence and do the needful to make the product error free. When it is delivered to the client, it should meet their expectations. You want happy clients!! Isn’t it?

Because of these reasons, in the above paragraphs, I said the success of the offshore model highly depends on the onsite coordinator. Do you agree with me?

Que 2. How can the client help in better deliverable quality?

1. Document all work. If you are working in any offshore model, good documentation is the highest proirity. The FDD should be as detailed as possible. There should be no scope for the developers to assume. There is no harm in cramping the FDD with extra information. But, if some information is not mentioned in the FDD, then the client cannot expect it to be delivered. In an onshore/offshore delivery model, there is no thing called it was self explanatory in FDD.

2. Provide the offshore team with information in black and white. If the client takes phone call sessions to explain the requirement, it is always helpful to share the screen as well. Seeing is believing. If you only speak in a call, chances are, the listener would miss something or the other. Reason can be anything like network issue or offshore team having some problem understanding certain jargons and pronountiation. Also, after the call, sending the MOM (Minute of Meeting) to the offshore group always help them.

3. Maintain proper version. If there is any update or change in the FDD, the versions should be maintained religiously. The FDD should not delete any requirement which is not needed. They should mark it as not needed in the updated versions but should not be deleted from the document. Such written information in the FDD helps the developers to explicitly identify, what is not needed.

4. Send small emails as token of appreciation to the actual developers (not the leads or onsite coordinators). Even a single liner like ‘Thank you for completing this object on time and budget‘ is enough for those hard working team. Offshore developers take pride in getting such emails. Those guys really work hard and they are told Client is God and Client is always right. Such gestures boost their morale and they would perform better. And the client can expect to get even better product next time. 🙂

These are my thoughts and understanding. Do you have anything more to add to it. Please feel free to email us at mailsapyard@gmail.com or leave it in our comment section. We would be happy to update/include our post.

If you want to get updates about our new tweaks and tricks, please subscribe.

If you liked it, please share it. Thank you very much for your time!!

Image source : www.rrdonnelley.com