1 / 23

Outsourcing Lessons From India

Outsourcing Lessons From India. Outsourcing specialist Hugh Walcott has learned his lessons the hard way - so you won't have to. These lessons come from helping an Australian company manage a large offshore project with a business partner in India.

gili
Télécharger la présentation

Outsourcing Lessons From India

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Outsourcing Lessons From India • Outsourcing specialist Hugh Walcott has learned his lessons the hard way - so you won't have to. • These lessons come from helping an Australian company manage a large offshore project with a business partner in India. • On the surface the decision seemed entirely sound • the Indian partner boasted strong expertise in the desired project area • claimed to have more than 16,000 engineers based in Bangalore, India • operating at CMM Level 5.

  2. But… • However, down at the project level things quickly started to go wrong. • The project simply did not go well, Walcott says - so much so that even today it still struggles in the face of that troubled history. • Key deliveries failed to be met. • The veneer of commitment and ownership promoted by the outsourcer started to crumble. • Problems were magnified by • distance • cultural difficulties • accusations • lies started to flow.

  3. It was even worse than that… • During the project, Indian team members seemed so relentlessly incapable of meeting deliverables that the company felt it had to arrange short-term visas for a portion of the Indian team to come to Australia in the hope of achieving some oversight and improved accountability. But if the camel's back was shuddering from the discovery that many of those so-called 16,000 engineers sported bogus CVs and lacked the necessary technical knowledge, the final back-breaking straw turned out to be the revelation that the much-vaunted CMM Level 5 rating was only applicable on site.

  4. Lesson One: Offshoring Taxonomy 101 • "Understanding how to structure an offshore project first involves understanding the associated risks and to structure the outsource agreement to manage these risks. For example, if the biggest risk to an organization is loss of IP, then an outsourcing agreement that ensures no complete solution is ever assembled offshore may be necessary."

  5. Taxonomy Categories: • Top level or solution level agreements • System level agreements • Sub-system level agreements.

  6. Unfortunate Surprise • On the project in question, the organization thought it was going for a system level agreement, but as problems started to occur it found itself with a sub-system level agreement almost by default. Inevitably, Walcott says, the vast physical distances between team members caused problems, not least in the challenges associated with expectation management. • "We never had the contingencies built into our agreement from the beginning. We were stuck: Our project deliverables were dependent on theirs and in order for the whole solution to succeed we had to help them out. Merging the two teams and consolidating the control of ownership of the project seemed to be the only way to get out of our nightmare."

  7. Lesson Two: Cultural Differences Are Important • When the deadlines first started to slip, the Indian team began lying about the progress being made, continually insisting all the work was on track. Walcott believes the problem was compounded as much by cultural differences as by the vast distances between the two teams at that point, with those lies inextricably tied up with the concept of "not losing face".

  8. Herculean Effort: Now in Order • It was in an attempt to overcome these problems [of saving face] that a portion of the Indian team were eventually given three-month working visas to come to work on the project in Australia. "That turned out to be a monster headache," Walcott says, "but we got the visas and put them up in a hotel in Sydney. With the visas sorted, everything seemed perfect. [We thought:] the Indians should be here for the expected length of the project. But integrating the two teams turned out not to be as easy as first thought."

  9. But, … More Cultural Issues: • Different attitudes towards time • Different work ethics • Different attitudes toward quality • Different attitudes toward cooperation: The Indian team chose to work in isolation and not accept help when it was offered.

  10. And “Status”: Maintaining the “Power Distance” • Walcott says companies must ensure that everyone understands the project reporting structure before engaging in an outsourced project. This needs to apply from the top all the way down the project hierarchy, including developers and tester. India, in common with many Asian societies where offshoring is prevalent, places greater emphasis on so-called "power distances" or status: the distance between members of an organization.

  11. Bugs?!? Oh, NO!!! • The next challenge involved resolving the technical difficulties. This is usually managed through some form of change management system, used to report bugs or enhancements, getting it fixed and ensuring that it works.

  12. Lesson Three: Choosing the Right Development Methodology • Countries like India place a much greater emphasis on teams over the individual. In India, as in much of Asia, it is the team that gets thrown a problem, not an individual. In Australia it is more likely that a trusted individual will be given carriage of a problem. • "Choosing a development methodology that can adapt to offshore and local working habits while also complying to your outsourcing agreement commitments is an important step."

  13. This “Group” Challenge Begets: • FDD: Walcott says Feature Driven Development (FDD) - a short-iteration process framework for software development projects - is a crucial tool in overcoming difficulties of culture and distance because it allows the project manager to break projects down into features, be they presentational or back-end, with each feature representing about two weeks' work.

  14. FDD • FDD starts with the creation of a domain object model in collaboration with Domain Experts. • Using information from the modeling activity and from any other requirements activities that have taken place, the developers go on to create a features list. • Then a rough plan is drawn up and responsibilities are assigned. • Now you are ready to take small groups of features through a design and build iteration that lasts no longer than two weeks for each group and is often much shorter - sometimes only a matter of hours - repeating this process until there are no more features.

  15. FDD: The Perfect Match for a Multinational (Offshoring) Project • Walcott describes himself as a "huge believer" in FDD, which is typically used in conjunction with agile development methodologies. "FDD was a perfect match for our multinational project," he says. "By assigning feature sets according to a project reporting structure, a project is able to maintain the correct cultural 'power distances' while maintaining individuals' accountability within the team.

  16. Lesson Four: Audit Your Progress . . . Carefully • "Outsourcing your project offshore is like a box of chocolates, you never know what you are going to get," says Walcott. "We'd seen the resumes of the staff we were working with, but when they eventually arrived on site they turned out to be completely different." • So, whose anxious to play in this sandbox?

  17. Audits Keep Honesty in the Game • Walcott says audits can be an invaluable tool in helping an organization expose and overcome such difficulties, although care is needed to maintain the business relationship. Audits can also be used to assess other aspects of the project, including both technical and cultural aspects. "Running an audit allowed us to expose shortcomings in both the resources we had assigned and how we were managing our project, allowing us the opportunity to rectify the problems before it was too late," he says.

  18. This isn’t easy, either • "With reverse engineering tools we were able to ascertain exactly what caused some of the problems we had experienced and what best practices we thought were missing. • So we did what we hadn't done at early stages, which is to say: 'We will not accept anything from you if it doesn't comply with best practices.' • This is something we should have done at the outset, and in future I would make that a part of best practice agreements."

  19. Picking and Auditor • In order to best protect the business relationship, an independent auditor should be agreed upon early and service level contingencies put in place as part of the initial outsourcing agreement, Walcott says. Depending on the type of agreement, organizations should look at including a clause demanding an independent audit of all work should deliveries fail to be met. Sub-system or collaborative outsourced projects required most attention, as it is the long-term objective of an organization to own, support and hence maintain the solution in-house. • Does this sound like it’s going to be less expensive?

  20. And the final result? • "After the end of the three months, when the Indians were about to leave, we still had a service level agreement with them but we did not feel confident from the experience that we had in even sending anything back to be fixed. The audit had helped expose just what a mess it actually was so a small team of us created a new project called the Refactor Project to rewrite almost everything they had done.

  21. This could get complicated • Managing the flow of work between enterprise and outsourcer is another area where audits are a useful tool. Areas such as change management, document control and build migration are all cross-cultural sensitive areas and are often overlooked by business audits. A technical audit can optimize these processes while • maintaining the correct reporting structure, • power distances and • self-honor (“face”).

  22. Walcott’s Conclusion • With offshoring likely to be around for some considerable time, due partly to the skills shortage, more and more organizations are going to engage in offshore agreements. Walcott's experience leaves him confident that companies that have been forewarned to likely difficulties, and who adopt a rigorous approach to audits, should be able to do so with greater confidence in future. • What is your conclusion?

  23. Value of time Cooperation/team wk issues Work ethic issues Quality of work issues Face-saving cultural issues Power distant issues complicating communication Time-zone issues Less flexibility due to contracted specifications Risks our I.P. No courts to control contract violations Most companies don’t see savings for 3 years Demoralizes local work force Language barriers Loss of control (not transparent, not directable) Increased testing burden Increased P.M. at detailed levels Better specs required (more time consuming) Trust issues (honesty issues) Difficult to assess true quality of offshore source due to bait-&-switch Added expenses of third party audits Cautions to consider (and plan and budget for) before outsourcing:

More Related