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 can pronounce the names of both the team members. The teams have identified and practiced local greetings that should be addressed in conference calls and other communications
  • The teams have a friendly open working relationship with each other, and that they communicate as per the need basis. The communication history is available and documented

Analysis and Design: Checklist
Ensure and provide the evidence:

  • The onsite team has developed the analysis and design documents (business and technical; referred as documents in the following points). The documents are detailed, clear and complete, and have been reviewed and approved by the appropriate stakeholders. The review and approval history is available and documented
  • The documents have been supported by examples, supporting documents and contain exhaustive test cases that verify the completion. The business SMEs have approved the test cases against the business requirements
  • Each document includes a feedback checklist, for the intended recipients (such as offshore developers) to complete, to ensure that the reader has understood the document
  • Each document, that results in a testable deliverable, includes a completion exit checklist, for the intended recipients (such as offshore developers) to complete, to ensure that the recipients knows what he/she needs to deliver in order to make the deliverable 'complete'. The completion exit checklist is such that once completed, it will produce the confirmable, verifiable and testable deliverable/li>
  • The onsite team has developed and published the test plans for the system and the integration tests. The business SMEs have approved the plans against the business requirements
  • The team members have documented questions, any missing information and clarifications on the documents, and sent them to the onsite team
  • The onsite team has addressed all the questions, feedback, assumptions and issues, have accordingly updated the documents. The feedback and update history is available and documented
  • Each document, that results in a testable deliverable, includes the success criteria for performance
  • Documents are available in a secured common area and accessible to the teams
  • The designated reviewers have been assigned–both onsite as well as offshore–against each deliverable. They are the keepers of the completion exit checklist against which each deliverable will be signed-off
  • Project managers have reviewed/revised the project schedule with each team member and that the members have understood the schedule as it relates to their tasks and deliverables
  • The technical and project standards have been reinforced (formal or informal) with an extra emphasis on project standards, communication, escalation and review mechanism
  • QA environment and QA plans have been put in place to test the technical deliverables
  • The detailed inventory of deliverables and assignments–on who will deliver and when–has been posted sparingly in the work place
  • The team members have a friendly open working relationship with each other, and that they communicate as per the need basis. The communication history is available and documented
  • If this is the first project, the onsite SMEs have identified the prototype features that will be developed before the rest of the application

Develop and Test: Checklist
Ensure and provide the evidence:

  • The development team has followed the technical and project standards. This has been demonstrated in delivery of the prototype system.
  • The technical and project standards have been reinforced (formal or informal) with an extra emphasis on technical standards, version control, communication, testing and review mechanism
  • Each team member, from both the onsite and offshore teams, is aware of the schedule and knows the communication hierarchy. The detailed inventory of deliverables and assignments–on who will deliver and when–has been posted sparingly in the work place
  • The team member, responsible for a deliverable, has verified the deliverable against the completion exit checklist before submitting the deliverable to the designated offshore and onsite reviewers/li>
  • Reviewers have verified the deliverables against the deliverables' completion exit checklist before signing-off. They have documented the review history, and is available for future references
  • The team members and the reviewers have documented technical and business issues, arising out of reviews. They have documented the issues and the history is available for future references/li>
  • Business and technical SMEs have attended to, resolved the issues, updated the appropriate documents, and published them to the appropriate members. They have also documented the update history, and is available for future references
  • The technical team has successfully applied the reviewer’s feedback in a timely manner. The revision history is available for future references
  • Project managers have reviewed/revised the project schedule after the reviews and that the members have understood the schedule as it relates to their tasks and deliverables
  • Onsite technical and business SMEs have tested all the deliverables, and have signed-off on them
  • Onsite technical SMEs have ported all the technical deliverables from the development to the QA environment
  • Production environment and the transition plans, for moving from QA to production, are in place, and have been certified by the appropriate SMEs
  • Each technical deliverable has met the performance criteria (such as response times)
  • The communication matrix, for the integration testing and go-live, has been published and the availability of the key members has been confirmed

Implement: Checklist
Ensure and provide the evidence:

  • All the deliverables have been completed and delivered as planned in the checklist inventory and the project schedule
  • Technical SMEs have completed the testing against the completion exit checklist, certified and signed-off on the all the technical deliverables. The review and sign-off history is well documented
  • Business SMEs have completed the testing against the completion exit checklist, certified and signed-off on the all the business deliverables. The review and sign-off history is well documented
  • Business SMEs have completed the system and integration tests against the QA plans, certified and signed-off on the all the deliverables. The review and sign-off history is well documented
  • The system has met the performance criteria (such as regression tests)
  • The key offshore personnel are available onsite to attend to any issues, in a timely manner, arising out of the implementation
  • The support offshore personnel are available, as per the implementation schedule, to attend to any issues
  • The release documentation have been completed and have been reviewed by the offshore and onsite technical SMEs
  • The lessons learned sessions have been held by involving both the teams, and the results have been incorporated in the technical and project management standards

As you would notice, my approach emphasizes on completing a ‘must have’ checklist. You should be able to tailor the above checklist to suit to your specific needs. But the point is that you must ensure that a checklist is completed and verified, in each phase, before proceeding to the next. You must fill the gaps, if any, by refining your processes, standards and/or deliverables to ensure that the checklist is satisfied. The responsible resources must prove that the questions, raised in the checklist, have been incorporated in the appropriate processes, standards and/or deliverables.

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.