A Checklist for Managing Offshore Projects

[article]
Member Submitted
Summary:

More and more companies are sending software development work offshore. While this practice allows companies to leverage an incredible talent pool at a lower cost, it poses significant challenges in managing projects. IT managers are struggling to perfect the process yet there is no proven way of managing offshore projects. In this article, Avi Verma presents a set of general guidelines for project and business managers to effectively manage offshore projects.

More and more companies are sending software development work offshore. While this practice allows companies to leverage the incredible talent pool at a lower cost thereby adding to the bottom line, it poses significant challenges in managing projects. IT managers are struggling to perfect the process yet there is no proven way of managing offshore projects.

In a project where the team is located onsite, you can afford to rely on the iterative process of refining the requirements, development and testing but in case of offshore projects, each phase should be considered more rigid and should be managed accordingly. A small oversight, for example, in the Analysis/Design may cause you a costly delay in the Development phase pushing your subsequent deadlines. Such a delay can escalate to the extent that the very purpose of going offshore may get defeated.

In this article, I will present a set of general guidelines, using a checklist, for project and business managers to use to effectively manage offshore projects. Using a typical life cycle of a software project–Plan, Analysis and Design, Development and Test, Implement–I will describe a list of checklist THAT MUST BE SATISFIED in order to make the offshore-onsite delivery process effective, verifiable and successful. The focus of the checklist is on the offshoreonsite aspect of the project only. It does not intend to cover the rest of the broader area of the project and delivery management.

Plan: Checklist
Ensure and provide the evidence:

  • Onsite program manager has published the project documents (such as project and technical standards, templates, schedule, and the necessary business and technical documents–collectively referred simply as documents in the rest of the plan checklist) in an "easy-to-get-to" area (such as an intranet site).
  • Both the teams (referred as teams) have been formally trained in the technical and project standards, technical tools and that the teams have practiced them. If this is the first project, the teams have successfully worked on a prototype project to demonstrate that they can effectively use the standards and tools
  • The teams have been trained in using the project management tools such as the review procedures, issue tracking, change management and escalation and communication mechanism. Again, if this the first project, the teams have used a prototype project to demonstrate that they can effectively use the tools
  • The onsite technical SMEs have setup a common secured work area (such as a secured intranet area), for both the teams, where they can access all the tools, templates and documents and that the team members have the appropriate access
  • The teams have clearly understood the roles and responsibilities for each of their members. The onsite managers have solicited the feedback from both the teams, and have appropriately updated the roles and responsibilities/li>
  • The onsite team has established a secured communication mechanism and the hierarchy of communication between the two teams/li>
  • Onsite SMEs and managers have established, published and both the teams have understood the metrics for measuring the performance on tasks and milestones as well as for measuring the effectiveness of the day-to-day communication
  • The teams have understood the scope, expectations on the project deliverables and the schedule of the project
  • The teams have provided feedback, raised issues and clarifications on the documents. The onsite SMEs and managers have reviewed the feedback and have appropriately updated the documents. The feedback and update history is available and documented. This process has been repeated until the documents are stable
  • The teams have the right skill sets and the right number of resources available
  • The project schedule includes holidays, vacations, working times etc. from both the teams
  • The teams

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Oct 12
Oct 15
Nov 09
Nov 09