2. Best Practices
• Proven expertise
• Past Track record
• Financial Viability
• Empower
• Accountability
• Communication
• Continuous Improvement
• Clearly Defined
requirements
• Do not require regular
interactions with local
teams
• Better use of resources
• Local team gets to focus on more
mission critical operations
3. Why
• Each company will have different reasons
for considering outsourcing and
specifically offshore outsourcing
• Typical reasons
o Proven expertise in a particular area (avoid re-inventing the
wheel)
o Cost savings, Higher return on investment
o Round the clock operations
o Ability to have onsite resources focus on more mission critical
tasks
4. Who
• Each company will have a different
process to select their offshore application
development partner
• Typical considerations
o Budget
o References
o Domain Experience
o Track Record
5. What
• Projects/Activities that have minimum day-to-day changes and
interactions with local teams
• Clearly defined projects or parts of projects
o Projects with well-defined scope/boundaries and or parts of
projects that can independently executed
• Does not mean no dependencies with other teams, just
means dependencies are also well-defined
o If requirements are not well-defined, take time upfront to do so
o Support Projects – Production support and small enhancements
make a good candidate
6. How
• Establish Accountability and Ownership clearly
• Empower the team with all the information and context needed to
understand the big picture
o Make expectations clear – clear list of deliverables
o Share all standards (design, UI, coding) you have ahead of time
o Treat them as an extension to your local team
• Hybrid methodology - Pure Agile won’t work until the team and
delivery rhythm is established
o Take time upfront to do detailed requirements analysis and
technical design with review process until you gain confidence
o Agile development model with frequent demos with early focus on
QA
7. How - continued
• Communicate, Communicate, Communicate
o Daily Stand-ups – if needed
o Weekly Status Calls, Weekly Status Reports – Mandatory
o Common document repository
o Common Issues and Bugs tracker
• Proactive Reviewing
o Design Reviews
o Code Reviews
o Sprint Demos
o Sprint QA
• Continuous Improvement
o Be open to learn from mistakes and alter the process until it works
o Each context is different and so there is no one size fits all process