Offshoring in ECM context

Recent announcements by GM and ABN AMRO clearly show that outsourcing and offshoring to multiple vendors is the way ahead. There are obvious benefits, however, there have been some concerns that offshoring has not been able to deliver the promise. In my opinion, this is not because of the fact that offshoring itself is not workable but because of the way people decide what to offshore and how to manage it.

In ECM projects, many things would be common with any other type of projects. However there are some specific issues that arise in CMS projects. Here are some points to remember in the context of ECM projects (based on my recent experiences):

1. Onsite presence: In a content management project, the involvement of authors, editors etc is very important during the project. This is important from the point of view of usability as well. Also, many a times, a CM project is a COTS implementation and most of the authors would not have seen specific features like workflow in detail. So it is important to keep them involved thru out. However, in an offshore onsite model, in order to reduce costs, some vendors try to increase the offshore component. This typically means that they have a very thin onsite presence and that too not thru the full life cycle of the project. This leads to more escalations, more telecons and more heart burns. Hence, if there is a reasonable onsite presence till the project is complete, the onsite team can coordinate with the client’s content people and thus reassure them whenever required.

2. What to offshore: Content migration or upgradation projects have some specific issues. In an upgradation project, you need to set up at least two environments (old and new, there are often more), have a good connectivity, VPN and so on. This, coupled with the issues in communication, offsets the cost benefits that one would have had by offshoring. In order to win a project, vendors often pitch in with this offshoring pitch which clients are too happy to buy without realizing the obvious pitfalls. Secondly, bigger companies have ODCs (Offshore Development Centers) and hence good connectivity to client’s systems. Smaller companies do not have that kind of bandwidth and hence the issues are even more.
Maintenance projects are good candidates for offshoring, especially if there is a large number of small requests. Because of time difference, by the time users come to work next day, the request would have been resolved. So no productive time is lost. Other examples: If the content management is for multiple languages, then you probably want to think of that too. So, not every thing can and should be offshored.

3. Time window for content entry: Sometimes, the client wants to start with the new system ASAP because they have huge content to enter or they have authors and editors sitting idle. A common approach in such cases is to define content entry templates and give them to users so that they can enter content simultaneously while the system is being developed offshore. This has implications because as the requirements change, one needs to change the content structure often – add/remove fields, add metadata and so on. Every time one does this, one needs to migrate already entered content. This approach works when developers and content guys sit together. But, in an offshoring scenario, things are not as smooth. So do not let content guys enter content before the project is more or less in a steady state. . Similarly in a migration project, do not let content guys enter content after a fixed date. Basically, one should define a time deadline after which no content should be entered. This helps with cases when content guys enter content when the migration is actually being done.

4. Multi vendor outsourcing: One of our large clients wanted to award us a CM project. They already had an offshore development center (and hence the whole setup) at another vendor’s place who happens to be our competitor. So they wanted us to execute the project using our competitor’s facilities! This had implications of poaching, IP, access control, use of facilities, our competitive advantage due to that product’s knowledge and other such issues. However, with more and more clients going in for multi vendor outsourcing, this scenario will become more prevalent.`

I will make this a running post and probably update it with more issues. There are quite a few other issues as well but they are generic issues for any off shoring project.

3 thoughts on “Offshoring in ECM context”

  1. Two competing vendors working from each other’s premises won’t work but there a lot of instances where they work together in neutral territory (i.e. customer premises). It may not be bad after all as each vendor will ensure that their part works well and the hand-offs are clean – so there is a smooth running system. It needs to be well managed by the customer to ensure that the whole is greater than the sum of the parts.

  2. There are so many different ways to do it, you’ll just have to ask them what they have in place. It’ll probably be an IPSEC or L2TP VPN, assuming they set that up in operations manager.

Comments are closed.

If you would like to get short takes directly in your mailbox, please do consider subscribing to my newsletter. I won’t spam you and your information will be safe. I usually send it like once a week (or once in 15 days).

%d bloggers like this: