How to Start an Outsourcing Relationship

software development outsourcing

I’ve recently posted an article about the importance of communications to software development outsourcing success. But the question is—What’s the right way to start outsourcing relationships if you are trying to keep that important aspect in mind?

We’ve been providing software R&D services for over 20 years, and we’ve developed our own approach to starting such relationships. In 2005–08, we introduced a few joint presentations with IBM that underline the importance of communications and joint workshops. Since then, we’ve continued polishing the approach, and I want to share some cornerstones of it here.

First, we believe that there is no need to spend more than 5–10% of the project efforts working onsite. A good communication plan allows spending more than 90% of project efforts offshore. That means, among other things, that we normally don’t use a permanent onsite person for teams smaller than 20 people. However, there are important moments in every software development lifecycle—launch time and integration time—when face-to-face meetings are necessary.

We typically recommend starting the software outsourcing service engagement with an onsite workshop. Two to three core team members travel to the client’s site for two to three weeks with a well-defined goal: to discuss and agree upon the communication model, joint development process, and initial roadmap; gather product/project knowledge; and get acquainted with the people they will be working with from now on. More specifically, a typical workshop plan usually includes the following:

  • Familiarizing the Auriga team with the product and project:
    • Architecture and code structure of the product
    • Existing testing infrastructure—framework, environment, test plans, coverage
    • Existing development infrastructure—repositories, tools, formats, coding standards
    • Existing production infrastructure—used frameworks and tools, customer specifics, access and control capabilities
  • Familiarizing Auriga with the client team:
    • Roles on the client side—engineering (development and testing), product management, deployment
    • Expertise distribution inside the client engineering team
    • Main points of contact for technical/business questions
  • Setting up the development/testing environment and process for the Auriga team:
    • Source code: provide access to the existing repositories, set up local repositories, define check-in/branching rules and procedures
    • Requirements: define the mechanism for specifying requirements for the bundles assigned to Auriga
    • Defects: access the existing defect tracking tool, set up local database if needed, define defects in workflows and procedures
    • Reporting and communications: define procedure for status reporting, define tools for status tracking, define procedure for demonstrations and acceptance, set up communication tools
    • Demos and acceptance: define procedure for work bundle demonstration and acceptance, set up tools
    • Testing: define strategy, test coverage, and traceability requirements; organize access to locale information
  • Estimating at least the first work bundle

After the core team members come back from the initial onsite workshop, they start training the rest of the team that was staffed in parallel with the workshop. Intensive knowledge transfer from the client to our team continues.

We recommend planning a special ramp-up project phase after conducting the initial onsite workshop. While performing the actual—but not too long or complex—task (such as adding a new feature to the existing project or implementing the first simple feature for a new one), the team concentrates on tasting and testing all aspects of joint operation: How does the communication plan, build/continuous integration/automated testing environments, joint repositories and tools, agreed procedures, and other aspects of project execution work in real life? It may result in significant revision of the collaboration process if serious deficiencies are discovered.

After the initial onsite workshop and the first ramp-up project, the team continues with the following:

  • Stabilization—finishing the ramp-up and knowledge transfer. This typically ends three to six months after the engagement starts. The first milestones are passed, sub-projects are completed, experience is gained, and the team is stabilized.
  • Optimization—post-ramp-up activities required for long-term engagement success. Balancing the team structure: The team consisting mostly of senior engineers is good for the initial period but is unstable in the long term, so junior members should be added to the team. Adding a secondary lower-cost location allows Auriga to propose and keep lower rates after the initial investment stage.
  • And finally, continuous operation and improvement. This involves implementing new versions, maintaining the product, improving the process, planning based on gathered statistics, and so on.

But whatever goes after the first stage, the basis for it is set during the initial workshop and ramp-up period. The main knowledge transfer, process decisions, and improvements that can lead to long-term consequences—good or bad—give grounding right here. Thus, it is extremely important to launch them with a clear understanding of the goals, required deliverables, and methods for obtaining information and reaching mutually beneficial agreements.

Source: http://auriga.com/blog/how-to-start-an-outsourcing-relationship/

Share Button

About author

Thao Nguyen

I am working as a Marketer at S3Corp. I am a fan of photography, technology, and design. I’m also interested in entrepreneurship and writing.