Offshoring ECM
ECM in an Offshoring Context
by Apoorv Durga
06-Jun-2006
Various commentators (McKinsey, IDC, Forrester) have been predicting big numbers for offshore outsourcing. Though analysts differ in the actual amounts and cost savings, the fact is that offshoring is here to stay. The benefits are obvious, and endorsements have come in the form of recent multi billion dollar deals announced by GM and ABN AMRO.
However, concerns have been raised that offshoring has not been able to live up to its full promise. This is not because offshoring itself is not viable but because of what companies decide to offshore and how they manage it.
In enterprise content management ("ECM") projects, the processes and issues arising are similar to those in any other IT project. Nevertheless there are challenges specific to offshoring ECM projects. The advice I offer below is based on my experience working from India on ECM projects for U.S. and European clients. (By "ECM" I mean any variety of content/document/records/asset management projects.)
Judicious Onsite-Offshore mix
In an ECM project, the involvement of content experts is very important throughout the lifecycle. Even though a content management project may entail an implementation of a commercial off-the-shelf product, most of the authors will not have seen specific features (like workflow) in detail before, which makes it all the more important to keep them involved through out. This is imperative from the perspective of usability, training, and eventual adoption of the CMS. The challenge lies in taking the business users into confidence at the very outset.
Another aspect that needs to
be accounted for is onsite presence -- at the client site -- during
the testing and deployment phases of the project. If there are incremental
deliverables, onsite presence is required throughout the project. What
I have experienced is that in an onsite-offshore model, to reduce costs
some vendors try to increase the offshore component. This typically
means that they may retain only a thin onsite presence, and perhaps
not through the full life cycle of the project. This leads to more complaints,
more time spent on solution-less telecons and in the end, more heartburn.
Similar issues arise in traditional application development projects too. The situation there, though, is relatively better because often it is a question of custom development with features developed exactly as visualized by the business folks. So development usually starts after getting a nod from all the stakeholders. However, in an ECM project, a product is usually selected and content people get to see how the features work (e.g., what a workflow looks like) only when it is implemented.
A reasonable onsite presence of key people (like a Project Manager, QA) until the project is completed will help ensure smooth coordination with the client's businesspeople who will ultimately accept or reject the system.
ECM product licenses
ECM product pricing is hopelessly complex. Most licenses are based on some combination of per-CPU or per-box or per-user fees and this can become a huge additional cost -- often borne by the client -- when the offshore integrator needs to license the product.
Ideally, the client's license would stretch across the distance to India, but sometimes, there are restrictions built into the licensing model whereby clients find it difficult to transfer their existing licenses abroad. For a three month project, if they have to buy additional licenses of products that cost as much as $50K per CPU, the total cost becomes unattractive.
You will want to find out if it would be possible to transfer development licenses abroad or if there are alternatives (like access thru Citrix). In my opinion, the ECM vendors should do what some of the application server vendors are doing: providing development licenses free to customers that have bought licenses for production.
When evaluating ECM software products, customers should add a requirement in their RFP to find out the "offshore-friendliness" of the vendor's licensing.
What to offshore?
It is important to decide what parts of a project can be offshored cost effectively. Generally, the cost savings are not simply equal to the difference between costs of onsite resources and low cost offshore resources. Communication, coordination and setup costs that arise because of a distributed team have to be accounted for.
As an example, in an upgrade project, one would need to set up at least two environments (old and new, plus often others), have good connectivity, VPN and so on. In addition, there are communication and project management expenses that offset the cost benefits. While large integrators typically have Offshore Development Centers (ODCs) and can ensure good connectivity to clients' systems, smaller companies, who do not have that kind of a setup, can come up short.
It is always wise to keep in mind communication costs, costs of setting up additional environments, and cost of setting up connectivity & bandwidth while calculating cost savings of offshoring.
Time window for content entry
Sometimes, the client wants to initiate the new system ASAP, either because they have vast amount of content to deal with or the content people are sitting idle. A common approach in such scenarios is to define content entry templates and let the content people enter content while the rest of the system is being developed. This can increase overall effort because as the requirements change, we developers need to change the content structure in turn -- e.g., add/remove fields, add fields for metadata and so on. Every time this happens, already entered content needs to be re-entered.
Once development is complete, the old system and processes need to be switched over to the new system. If the content is being entered when this switch over is happening, all that content needs to be re-entered in the new system.
This approach to content entry from day one or until the very end may work when developers and content owners sit together. But, in an offshoring scenario, things are different because content people and developers are geographically separated. In short, it is harder to do "agile" ECM development in an offshoring situation.
You should define a time frame for content migration during the project lifecycle and content should be entered only during that specific window.
Multilingual Content Management
If a project involves outsourcing content entry or content translation, it should be ensured that the vendor has appropriate language skills. The bigger vendors usually have alliances with language specialists. Alternatively, a client representative, who understands the nuances of the language and is comfortable with handling issues that arise due to cultural differences, is involved.
Similarly, applications intended for a global audience have their own challenges for offshoring. It is generally easier to create an internationalized application by using standard techniques. However, localization is a greater challenge because the offshore integrator may not have people who understand the language and its cultural implications. So when they are testing the application, all they can test is if the application displays "another" language but not the fact that this display is meaningful.
Finally, there is a consideration for offshoring location. Apart from India, other emerging sources of outsourced IT talent are China, Philippines, countries in Eastern Europe, Mexico, and Brazil. China could be considered by clients in Chinese markets or for clients who have a presence in Japan and/or Korea.
It pays to involve a vendor who has suitable language specialists and/or make your own language experts a part of the development team.
Multi vendor outsourcing
One of our bigger clients wanted to award us a CM project. They already had an ODC (and hence the whole setup) at a different integrator's location in India who happens to be our competitor. The client desired that we execute the project using our competitor's facilities! As you can imagine, this might have raised the specter of poaching, IP, access control, use of facilities, as well as erosion of our competitive advantage due to product knowledge and similar such issues. Yet, with more and more clients going in for multi vendor outsourcing, this scenario will become more prevalent. A similar issue can arise in domestic outsourcing as well. However, the issue is more prominent in offshoring because typically offshoring projects are awarded by a specific client to a small set of preferred integrators who usually are comparable in terms of scale and size and are often direct competitors (like Wipro and Infosys).
Before deciding on an offshoring vendor, an analysis of the competitive landscape should be undertaken and care should be taken to avoid overlap of work between integrators when there is a chance of conflict.
Access to Production Systems
Often the offshore development environment is different from the onsite production environment. This could be because of different configurations, patches, service packs, or even unavailability of all the applications offshore. Because of this difference, there are situations when a system that works perfectly fine offshore fails onsite.
In a recent project, the CMS that was developed offshore was integrated with a single sign-on product for serving as a gateway to all customer applications. However, when this was sent onsite, the integration just did not work! The client being a first-time outsourcer was hesitant in providing access to production environment. This made it impossible for the offshore team to figure out the reasons why the CMS was not running. In absence of this access, the team had to rely on log files sent thru emails to sort out the issue. In the end, it turned out to be a simple thing that could have been easily figured out given access to the console. This just added to the overall effort. If the same issue arose in domestic outsourcing, it would be relatively simpler to troubleshoot because of geographical proximity. Also, it would be easier for the integration team to just go to client location and look at the logs.
Hence, before the start of the project, there needs to be mutual understanding of the importance of open access to appropriate systems. Usually, it is just a case of misconceptions that can be cleared through education. It also helps if the integrator has tighter guidelines and regulations in place to ensure protection of client data.
Conclusion
The issues addressed above arise in traditional application development projects too. However, ECM projects have their own unique challenges. This is primarily because of the fact that each ECM product has a different way of implementing specific features. What this means is that the content people need to be a part of project throughout its lifecycle and there is a greater need for user involvement than with most other application development projects.
Some of these issues are also prevalent in domestic outsourcing. But in that scenario, the vendor and client are typically in the same time zone and geography, and which mitigates some of the issues related to language and culture. The issues related to communication and distributed teams are not as pronounced as they are in offshoring.
The world is indeed getting flatter everyday. Offshoring in general and ECM offshoring specifically can be beneficial. However, one must exert caution and do a proper analysis before deciding on an offshoring project. This must be coupled with good project management, communication, coordination, and supplier selection.