If you’ve been working in the software development industry for the last five years you’ll have heard the increasing clamor to use offshore development resources. Most of the initial interest on offshore was focused on the significant cost savings that it could offer, however, recently these claims have been enhanced with promises of increased quality thanks to the high CMM certifications of many offshore development organizations. This article is a quick primer on some real world experiences that might help you if you’re either thinking of following this approach or you’re in the midst of an offshore development project.
Regardless of some of the promises you might have heard, offshore development will only help your project save about 15-25% of its costs. Why? Because the most logical piece of a project that can be outsourced is the ‘commodity’ oriented programming component. Unfortunately, programming represents only 30-50% of a software development project’s total costs. The rest is taken up by project management, requirements/analysis and design, testing and ancillary activities (like configuration management and environment preparation). Unless the project has very well defined requirements and has been well designed (which places many mainframe development projects into this category), you won’t see the 100-200% returns many offshore development organizations are touting. However, the opportunity to save up to 25% of your project costs can be quite significant, particularly these days.
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.
Communicate, Communicate, Communicate
If you thought your current projects are challenged by lack of communications you might want to re-assess your capacity to support an offshore development project. Regularly scheduled conference calls, e-mails and chat sessions are a must for managing these projects. Not only are these sessions for sharing information and establishing a clear perspective on the status of the project but they are also important for avoiding any of the miscommunication which can plague an offshore development project.
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:
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).
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!).
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.
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 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.
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).
Tools are an important mechanism to support most of the communication needs identified above but they can also be important in managing more discreet elements of an offshore project, such as requirements management, source code and defect tracking. Selecting the appropriate tools for your offshore development project should align with your enterprise tool requirements but the tools you use are going to be an important component of your offshore development strategy. Regardless of the tools you select it is important to validate that there are no barriers for their use in your offshore environment. Tools need to have the ability to synchronize easily through either the internet or a VPN. Ensure that there are no barriers to using the tools like operating system or browser differences between your onsite and offsite locations. Agree on the use of tools before the project and test them to make sure they work as required. If you don’t have any tools to manage your development effort you might want to consider this before embarking on an offshore development project.
Regardless of where you decide to outsource your development efforts (India, Pakistan, China or elsewhere) it is important to recognize that there are differences between your culture and the culture you are dealing with. Although this is a difficult area (fraught with all sorts of ‘political correctness issues’) some things you want to document prior to the start of your project include:
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.
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.
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.
The CMM Conundrum
Increasingly, many offshore development organizations are touting their CCM level 5 certifications as a way to differentiate themselves in the offshore market. There are two things about these certifications that I have observed. The first is that it’s not entirely clear how these certifications are assessed and how credible these assessment truly are. A number of offshore organizations that I have seen with CCM Level 5 certifications did not have any true standardized processes and certainly none that could lead to consistent and repeatable software development results. However, this leads to my second observation which is that there is a difference between an organization’s CMM certification and a project’s CMM level certification. Although your offshore development partner might be a CMM level 5 certified organization this does not necessarily translate to your individual project. Ask how your offshore development partner will support your project with its CMM processes, ask if any of their projects have been assessed using the CMM process.
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.
The Final Analysis
Offshore development does work and it does save you money. However, there are many things to be aware as we have seen before embarking on your first offshore development project. I would recommend two things to organizations considering this approach to their software development needs. The first would be to conduct an internal readiness assessment to see if your existing processes, infrastructure and tools can support an offshore development initiative. The second thing would be to trial offshore development with small and relatively low risk, internal application. These two steps can help you move through the learning curve with a lower degree of risk than betting the farm on a large engagement.