Offshore project management steps and life cycle

How to manage remote offshore teams in software development

But working with programmers on the opposite side of the world can be a challenge. Managing an outsourcer is clearly very different from managing an in-house development group, and we’ve found remarkably little discussion of how to make outsourcing relationships more successful. So, we decided to share our expertise in Offshore IT Outsourcing that our Project Management Team has gained during the implementation of more then 100 projects in the last 12 years. Our company, SoloSoft, is a 50-person outsourcing firm with offices in San Francisco and Europe. We offering the following insights:

1. First, think about how you’ll interact with the outsourcer: there’s a common misconception that you start out by preparing a product spec and then just hand it to an outsourcer. In actual practice, project specs emerge through a process of progressive investigation and analysis”—and the success of this process largely depends mostly on how completely the outsourcer and client communicate with each other about the project goals and the client’s overall business strategy.

2. Start small: “Your first goal, and the Offshore IT Provider’s, should be to make your initial project a success,” Rafael notes. “This goal is a prerequisite for meeting your other goals for outsourcing, such as cutting costs or getting to market faster. One way to succeed is to choose the right kind of pilot project, one that’s amenable to success, so you can forge a relationship and learn how to work effectively together.” Good projects involve minimal risks, are relatively easy to define, and have few dependencies

3. Don’t get derailed by the RFP: Clients sometimes rely on a detailed Request for Proposal to collect bids from a dozen or so potential Offshore IT Service Providers, and then hand the bids over to a purchasing department for final selection and pricing. From the outsourcer’s point of view, RFPs usually contain only 50%-75% of the real requirements, at best. At worst, they contain errors in estimating the size of the work and the skill levels required.

4. A better approach, is to start by identifying just two or three likely outsourcers and then work with them to prepare a more substantive Project Overview document. “The PO should start with high-level descriptions of the business need and the outsourcer’s solution,” says Rafael. “It should also describe delivery mechanisms, acceptance criteria and procedures, and, of course, a timeline and price for delivering the solution. A PO also covers legal and contractual issues such as ownership of property, terms and conditions of payment, and limits of liability.

5. “The PO will tell you a lot about the outsourcer besides its price,” he adds. “The more details you have about how the product will be delivered, tested, and accepted, the fewer unpleasant surprises you’ll receive in the future.”

Most software development projects are similar to the Software Development Life Cycle (SDLC) which includes 5 main phases:

• Requirements Phase - Gathering requirements;
• Design Phase - System design and planning;
• Development Phase - Coding and unit testing;
• System Testing - Whole system testing and integration;
• Release to Production - Deployment and release to production.

When we work on a software development project our PM team follows not only the best project management practice, but also software development methodologies that our development team use.

SoloSoft team follows the basic principles of the Rational Unified Process (RUP) as well as depending on the project may apply the popular now XP, RAD or even Agile development approaches. This is a de-facto leading standard for software development methodology, used by the leading companies in the IT field. Companies like Microsoft and IBM are partnering with Rational to make use of RUP and create joint products supporting RUP.

The core ideas of RUP (iterative development, sustainability to changes, careful QA and risk management, etc.) are very much suitable for our situation, in which we often work with dynamic business cases. On the diagram, the horizontal trends represent activities. The graph shows the amount of activity spent in each phase. On the whole, the graph illustrates how various activities (efforts) are spent among various project phases.