by Bryan Campbell  

If your system is a high novelty system you won't be able to avoid the need for proper requirements gathering and analysis and design.  Unfortunately, this process needs direct access to users and business stakeholders which requires an onsite presence.  Before embarking on an offshore development project, you need to understand where your organization's capabilities reside.  If requirements gathering and analysis and design are skills that are readily available and which have hardened processes you are probably in a good position to capitalize on offshore development.  If not, then spend the time necessary to develop processes and skills to support these important workflows.  It's easy to lose the benefits of cheaper offshore resources by inefficient re-work if requirements are not adequately documented or communicated.

I would strongly encourage defining a communication strategy for your offshore development project.  This should document a number of important communication techniques such as the frequency of scheduled conference calls with the entire team, the use of chat tools, whether or not video conferencing will be supported, application sharing tools, how to use e-mail and the use of a repository to manage project artifacts:

Conference Calls:  It is important to have regularly scheduled conference calls with the whole project  team.  The calls should be conducted by the onsite and offsite project leads although everyone should have an opportunity to participate.  Calls should be carefully managed to ensure they start and end on time.  Detailed issues should be assigned to individuals to be followed-up offline.  Issues and tasks should be documented and entered into a tool which can be accessed by the entire project team at any time. It might be necessary to have a variety of project conference calls for different teams based on the size of the project (some involving the business owner/customer and others with only the project participants).

Chat Tools:  Tools like MSN Messenger and Yahoo are indispensable to managing offshore projects.  However, it is important that everyone have an assigned ID, that these IDs are communicated throughout the team and that project members follow some form of 'etiquette' (since not all issues can be resolved by instant messages!).

Video Conferencing:  If you have access to good video conferencing facilities I would recommend using them, however, these require high bandwidth and more sophisticated equipment than the $100 webcams that are becoming increasingly popular.  Video Conferencing due to its cost and the challenges of setting it up is probably best for formal status updates which should only occur every week.

Application Sharing:  One area that can greatly aid collaborative development with an offshore team is exploring some of the application sharing tools that are available.  These tools allow teams to 'whiteboard' different solutions and to work on a common document together (such as a use case or architecture diagram).  These tools are very useful in place of the brainstorming that onsite teams often are involved in.

E-mail Usage:  E-mail is an important mechanism for sharing information between onsite and offsite teams.  However, it should not be used to replace other components of your communication strategy, particular a document repository.  All too often, e-mail is used as a mechanism to share artifacts, the risk is that these artifacts can be difficult to track and manage.  It can also be difficult to ensure that everyone has the most current version of an artifact.  For offshore development projects this becomes a critical risk.  To address this, guidelines should be drafted for the project where documents are transmitted via e-mail only in unique circumstances.  Otherwise, all documents should be placed in a repository and notifications of these deposits provided through e-mail with a link to the back to the repository.  Using e-mail for short, focused forms of documented communication is the best way to use this technology for project communication purposes.

Document Repository:  A commonly accessible document repository is an important tool for facilitating communication within an offshore project.  A good document repository should be accessible 24/7 (remember your offshore team will need access to information primarily during the night).  It should also support versioning of artifacts and provide a check-in/check-out feature (all things that a Configuration Manager will be familiar with!).  I would also encourage you to keep the interface and any document properties fields as simple as possible.  Many document repositories have rich interfaces which can cause unnecessary delays in loading pages particularly from offsite locations if there are any bottlenecks in network speed, also adding too much detail about the properties of a document being uploaded to a repository (such as document class, sub-class, status etc.) can also be needlessly demanding for the real needs that a repository serves (namely providing a common location for all project related material).

Holidays:  Make sure that national or other holidays are documented at the start of the project.  These holidays can have a significant impact on a project, particularly since most holidays don't align well between countries.  For example, November can have a lot of holidays between the US (Thanksgiving) and India (Deepavalli) which can significantly reduce project productivity.

Infrastructure:  Many areas where offshore development is conducted can be prone to infrastructure challenges.  Although most industrialized countries are not familiar with these issues, brown-outs and entire city power failures can and do occur in offshore development environments.  When selecting an offshore development partner ask about about how they are supported for power outages (back-up generators etc.) and whether they operate in a high-priority area for phone and electrical services.

Language:  It can take sometime to get familiar with the accents of individuals from different states or counties let alone different countries.  Usually this process requires time and practice so expect to see improvements throughout the lifecycle of the project.  Also remember that verbal communication can be more effective than written communication since writing skills in the software development industry are typically pretty weak anyway and are only exacerbated when you involve writing in a second language.  I try and have a quick review of any significant correspondence before it is issued to customers or business stakeholders.  This quality assurance function should be formally embedded in your project in some capacity simply to avoid any confusion (or possibly hurt feelings) caused by a language challenge barrier. 

Also be aware that while a high CMM certification might give you greater comfort you are dealing with a credible and quality oriented offshore development partner, you need to also be aware that this can come at the expense of flexibility and agility.  This might be fine for a mission critical system but you might want to think about whether something so important is the right candidate for an offshore development project.  The most important thing to be focus on is how your offshore development partner adjusts to deviations from its CMM processes.  How these difference are managed can influence how well your own organizational processes can work with them.

Bryan Campbell

Bryan Campbell is the Director of Consulting, Southeast with Valtech Inc., a software development company specializing in object oriented developing using the Unified Process.  Mr. Campbell has spent more than 15 years in the information technology industry across a wide range of disciplines ranging from operations to enterprise architecture to software development.  Currently completing his MBA specializing in Information Technology Management, Mr. Campbell has managed a series of large scale IT projects including software development projects using iterative development techniques.  Mr. Campbell has worked in a variety of industries including Telecommunications, Utilities and Insurance.  He is the author of several articles on software development and has presented at several conferences.