Offshore development best practices

Abstract

This paper describes an actual case study of a large systems development application using an onsite-offshore team. The best practices to reduce project risk, improve quality control and assurance and ensure the timely delivery of a large systems project using an offshore-onsite team are discussed by the IT Project Leader (Customer) and the Program Manager (from the Vendor/ Systems Integrator). They will share their real life experience of the pitfalls they experienced and provide their perspective on project management actions that can be adopted to ensure success.

Introduction

The cover article of BusinessWeek’s January issue talks about the Future of Outsourcing and Offshoring and quotes the Mckinsey Global Institute estimate that $18.4Billion in global IT work has been shifted offshore but the total potential is 10 times as much. (Engardio, Arndt, & Foust, 2006) One of the main reasons that the full potential to offshore all the available work is that large IT projects run into significant problems when they are sent offshore.

Baily and Farrell in the Mckinsey Quarterly (2004) have identified the advantages of Offshoring and these include in their words, “…the quality of the services they can buy is often higher: wages are lower, so companies can hire better-qualified people…offshore workers are often more highly motivated than US workers and perform better.” (¶7) Gartner said IT operations are eschewing the purchase of “expensive oversize software that requires complex implementation projects” (Gardner, 2004, ¶2) in favor of automation and the use of offshore outsourcing to lower costs.

We also have seen some significant failures using off shoring (examples of offshore failures). This item is parenthesis is redundant of what is said just before it. Goolsby and Keaton (2004) have identified the most frequent causes of failure as specified below.

Exhibit 1 – Most Frequent Cause of Outsourcing Failures

In this case study we describe the work done specifically during a two-year project for a large application development project using this offshore engagement model. We describe the specific project tasks that will ensure that the touted advantages are truly realized and also share some of the pitfalls experienced and provide some tips on how to avoid/overcome them. Tom Friedman in his book The World is Flat (2005) has exposed the world to the realities of an outsourced world.

Scope (Case Study Background)

Tyson Foods engaged Satyam as an offshore vendor to build an extensive system to manage their transportation operations. The system would manage 20,000 shipments per week consolidated for 3 divisions of Tyson as well as all third party backhaul shipments for it’s private fleet.

The project included the requirements engineering (see paper by Sankar, Yeleti and Hakeem (2005) , technical architecture, technical design, code development, testing and deployment. The core dedicated team consisted of 5 Tyson business functional leads, 3 IS Analysts, 4 Satyam functional and technical leads onsite and a dozen programmers offshore. Additional Tyson analysts and business leads have been engaged onsite at peak periods as needed with additional offshore resources also were added as needed for periods of time.

The major deliverables included:

• Functional Requirements: collecting and documenting the requirements into approximately 200 use cases in about three (3) months
• Technical Design: 1640 classes and the related sequence diagrams in about three (3) months
• Code Delivery of over 1910 objects with over 500,000 lines of code in Phase 1 in six months (6) to satisfy over 700 test scenarios each with multiple unit test criteria
• Code Delivery of an additional 500,000 lines of code over the course of another 6 months with over 500 test scenarios
• Code Delivery of 15 interfaces with 6 external systems on varying platforms utilizing 4 different integration technologies.
• Training, User Acceptance testing and Deployment over the final three (3) months before the go-live date for both Phase 1 and Phase 2.
• Detailed data model with over 200 database tables with over 1200 fields during the period of the functional and technical design.
• Report database design.
• Cognos Report Net data model definition and approximately 50 reports.
• Configuration and deployment guide documentation.
• Interface and integration documentation

Key Advantages

In the course of the project the key advantages gained included:

• Tremendous Cost Savings of about 50% based of labor arbitrage and an onsite: offshore ratio of 20:80 for contracted resources. (This team was 5 to 20 for Satyam with 8 Tyson onsite)
• 24 Hour Work day (follow the sun work effort);
• Faster Turn around of issue resolution
• Flexible workforce to add specialized technical or functional resources as appropriate;

Additional development environments. Having an offshore development environment gives an additional place to be building the next phase while testing the current phase onsite

Major Pitfalls to watch for

The main pitfalls that we had to overcome include:

• Turnaround time, beware of the 24 hour myth.
  • There are many occasions when you actually end up loosing 2 days instead of gaining a day using round the clock workforce. You must avoid the temptation to quickly send the issue offshore without doing the proper documentation and exchange of communication between onsite and offsite. Document and discuss directly with offshore, get confirmation back on the issue before work begins. This requires the onsite integrator to work hours at the start and end of every day that coincide with offshore.
• Miscommunication of the specificity of problem.
  • Document with examples and pictures if possible. Make sure feedback occurs to assure the right issue is being addressed.
  • Functional and Screen Prototypes help develop common understanding across the teams.
  • Make sure offshore has access to the onsite development environment to see the issue.
  • Make sure offshore gets an updated database with real onsite data frequently.
• Make sure your organization is ready to support 24 hour development.
  • Many support teams such as database, server support, networking, security etc. will not be willing to take development issues outside of normal business hours. You must get management commitment to support offshore development.
• Break the language barrier.
  • Work on listening; People can all speak the same language but not understand due to dialects.
  • The communication language barrier must be broken. Encourage and demand that your team say “I didn’t understand”. People don’t easily admit to not understanding you when you talk to them. This is much worse on phone conversations.
  • Develop feedback methods to ensure understanding.
  • Include someone in all cross language communication participants who can communicate well in both dialects.
  • Create meeting notes in a timely manner.
  • Require onsite review and approval of all design documents.
• Dependency on external teams/ resources.
  • Make sure you get commitments from external teams you are reliant on such as database, networking, server support, and technology teams.
  • Set schedules and communicate progress or changes often.
• Traceability matrix implementation across work products to verify the requirements are being covered and to the level of granularity desired.
• Delivery team not communicating inability to meet deadlines in a timely manner.
  • Missed deadlines cause all supporting teams to reprioritize and juggle other planned activities, this water fall stresses relationships and impacts future cooperation.
• Retention of resources
  • This is a common issue associated with long term projects, but with onsite/offshore mode you must be especially sensitive due to visa issues delaying replacement of those onsite resources. Make sure alternate resources offshore are visa ready if needed.
• Offshore team can be expanded to develop increased requirements faster, but the onsite team has to be able to accept, review, approve and test to keep up with that increased capacity.
  • When adding resources offshore, be sure to balance the onsite capacity.
  • Adding programmers means more will be ready to test/review faster from offshore, but the onsite team may not be able to keep up. Be sure to balance the entire schedule, not just the offshore development.

Check list

Specifically the check lists of processes followed include:

• Create a comprehensive list of tasks and work breakdown structures and identify the dependencies on both internal WBS and external systems and resources
• Make these tasks transparent across all members of the development team.
• Involve offshore team in requirements documentation. This ensures proper understanding has reached the development team. Pushing requirement documentation to offshore saves money in time twice, first when creating the requirement documentation with lower cost offshore resources and then when development begins since offshore picked up this knowledge while creating the documentation.
• Establish functional and technical resources onsite that speak and understand all languages and dialects that are involved in the project. These resources will be required to work 14 hour days and must be diligent and reliable. The project will succeed or fail based on their ability to communicate with onsite and offshore both at the beginning and end of the offshore day.
• Daily meetings with the offshore team to understand the true status of the issue resolution (not just the nominal status)
• Plan for dialect transition for the offshore team (even for people with good English skills we experienced a 2 week lag before they were 100% on par).
• To overcome listening “deficiency” repeat what you understood the other party to have said. Document meetings and publish notes in a timely manner.
• Don’t be afraid to - ask for clarifications or say “I did not understand”. You need to communicate early in the project that this is not only acceptable but expected and admitting to not understanding is the only way to succeed.
• Work thru the onsite team of the integrator but also have continuous verification with the offshore team directly. Offshore needs contact with the client to establish urgency and importance as well as praise and encouragement.
• Pick the right team – a mixture of tech skills, business area knowledge and communication skills
• Make sure that the organization is truly committed to a 24 hour development cycle – the Dev environment should be up 24 hours, there is no longer any “down” time in the dev environment and all support systems need to be up
• Follow up with meeting minutes or notes from the meeting diligently
• Make sure offshore delivers an Internal Design Document for all deliverables. These documents will provide written evidence of the requirements being understood and that onsite agrees on what is being developed.
• Build and maintain the Knowledge repository of all documentation. This should be accessible from both onsite and offshore. Have a formal induction process for all new team members. Team members typically must be informed along the dimensions of technical design and standards, business domain and the project management process.
• Follow a rigorous process for induction of new team members to ensure smooth transition. (See Exhibit 2 below).
  

  Exhibit 2 – Induction Process for new team members

• Establish Change Management procedures and follow them.
  • Document all changes to requirements, additions and removals.
  • IS Lead, Business Lead and Contractor Lead must agree on the requirement being a change in scope or functionality. This needs to be a fair, give and take relationship, but the guide lines must be established before the project begins.
  • Require business stake holder approval for the change before investigating
  • Require estimate and impact analysis for any changes
  • Require steering committee approval of the change cost and impact.
• Be fair to your partner. Everyone needs to be successful, make sure all parties balance their needs, costs, errors and successes so that a positive relationship is maintained.
• Manage Changes internal and external to the team. Be sure to manage and document scope reduction as well as scope increases. External changes for standards and software may have impacts not immediately foreseen, be sure to document these as they occur.
• Frequent meetings with the project stake holders. Keep your stakeholders involved in the project. For large long development projects it is important to not lose the direction and involvement of your stakeholders.
• Test cases are critical. Identifying unit and scenario test before the code is developed will improve the understanding and reduce communication issues. Make this process part of the design stage of the project. Design flaws will be identified when you define your testing requirements.
• Negative testing is a must. Make sure the application can handle unexpected data in an acceptable presentation manner.
• Manage source control onsite and offshore. Do not accept full deployments from offshore, compare object versions and follow check-in and check-out procedures at both onsite and offshore to ensure no code changes are either missed or lost.

Value Achieved

The team built and delivered against all the deliverables specified in the scope and went live with the system with Phase 1 within 15 months. This phase had about 200 users and the system was processing about 15,000 shipments a week.

The flexibility of being able to add resources in a rapid fashion at offshore to alleviate delays, blossoming errors or increased complexity allowed the project to keep getting back on track when it was veering out of control with delays. Development team was doubled at points to meet the delivery deadlines. Involvement of technical team in requirements documentation gave them the functional knowledge that enabled multiple team members to step up into lead roles as developers were added.

Using the offshore model we were able to reduce our costs on a comparable basis by about 30-40% of the costs if the system had been built entirely onsite. These costs savings were achieved both with the lower offshore labor rates at and with the offshore work ethic that generated 60-70 hour work weeks for many team members.

Conclusion

Developing large systems using an offshore vendor for end to end development can work very well. However, you must be prepared to commit yourself to recognize the specific pitfalls that are likely to arise. Specifically, pay attention to:

• Communication
• Organization commitment
• Onsite/Offshore contact at start and end of each day.
• Balance of onsite resources against offshore, push as much work offshore as possible.
• Give requirements to offshore, require design documents back to ensure understanding.
• Require test cases before development.

Finally, Manjeet Kriplani (2006) talks about the pitfalls to avoid but his most critical advice is “treat your partner as equals”. The key is to ensure that your company is committed to the process and that the team you build integrates quickly, melds offshore and onsite resources, and unifies vendor and client resources to work as One Team.