Offshore Development Model in 10 Steps Guide

8/11/2015 Offshore Development Model in 10 Steps | SAP Yard
http://www.sapyard.com/offshoredevelopmentmodelin10steps/ 1/10
Offshore Development
Model in 10 Steps
TOPICS: Offshore Outsourcing Onsite Offshore Model
Right Offshore IT Model
POSTED BY: SAP YARD JULY 25, 2015
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
Enter email
Subscribe
RECENT POSTS
DELETING rows of the
internal table within the
LOOP. Is it a Taboo? A big
NO NO?
Quick Reference for Vistex
Technical
Offshore Development
Model in 10 Steps
SAP YARD
YOUR BACKYARD FOR SAP TECHNICAL TIPS AND SOLUTIONS
HOME SEE ALL POSTS ASK YOUR QUESTIONS ABOUT ME CONTACT ME
You and 92 other friends like this
SAP Yard
168 likes
Liked
SEARCH …

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”.
Ready Reckoner for SAP
Developers
Just a key and two clicks for
ALV consistency check

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
11
10
9
1
1

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.
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
Previous post Next post 

BE THE FIRST TO COMMENT
ON "OFFSHORE DEVELOPMENT MODEL IN 10 STEPS"
Leave a comment
Your email address will not be published.
Name *
Raju
Email *
respond2raju@gmail.com
Website
Comment
Post Comment
COPYRIGHT 2015 | SAPYARD BY WWW.SAPYARD.COM
ALL PRODUCT NAMES ARE TRADEMARKS OF THEIR RESPECTIVE COMPANIES. SAPYARD.COM IS NOT AFFILIATED TO SAP AG.

Offshore Development Model in 10 Steps Guide

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (9)

Ähnlich wie Offshore Development Model in 10 Steps Guide

Ähnlich wie Offshore Development Model in 10 Steps Guide (20)

Mehr von SAPYard

Mehr von SAPYard (10)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Offshore Development Model in 10 Steps Guide