Pragmatic Outsourcing

Tips, tricks and traps of IT offshore outsourcing

Steps towards Disposable Outsourcing

If you imagine a graph representing extended cost of outsourcing (cost that includes your out-of-pocket expenses and the internal cost associate with enabling outsourcing) over time you will see substantial spikes in the beginning and end of the relationship. Minimizing or eliminating these spikes is one of the goals of DOM, the first spike of course can not be avoided. The cost could be minimized or eliminated for the first spike on consequent engagements. There other benefits of the model related to quality of work, impact of staff turnover, and so on. DOM can be applied to many engagement models and by all means worth efforts you put in getting to it. Below are some of the best practices that help immensely in building outsourcing relationships in DOM manner.

General. These are some of the best practices which apply to outsourcing engagement independently of the content of the engagement, technology, and scope.

  • Multisourcing. The term is typically used when multiple vendors are used across engagements. The first, most important benefit of multisourcing comes from “the best tool for the job” model. A particular vendor can offer great services in .NET development while another company has expertise in localization, and another in security monitoring. In terms of DOM I recommend taking multisourcing to another level, specifically using multiple vendors for the same task, of course if the size of engagement allows. For example QA team of 20 people can be easily outsourced to two vendors.
  • Cross-sourcing. I have to admit – there is no such term and I can use some ideas on how to name the following best practice. The idea is to use different vendors on different stages of SDLC, for example development is done by one vendor and QA by another. The objectives here go beyond “the best tool for the job” model aiming for vendors keeping each other honest.
  • DOM Planning. You need to develop your plan for execution of DOM, in particular for engagement termination and switching vendors. Even very large initiatives and comprehensive long term engagements sometimes have to undergo drastic changes. The level of planning and complexity of organization that supports it depends on the size of the outsourcing initiative.
  • Testing. I mean testing the DOM itself, verifying whether your outsourcing partner is indeed disposable. It’s impossible to overestimate the importance of testing DOM. Compare it to a Disaster Recovery planning. You may have a great plan, offsite storage of backup tapes, backup generators, etc. and yet if you never tested the process when disaster strikes that will be a disaster. The generators won’t start, the backup tapes won’t restore, etc. An example of efficient testing could be using two teams on the same engagement (see multisourcing above) and switching the teams. And that can happen to anyone.  See Satyam banned from offshoring work with World Bank, and consider what World Bank had to go through.

There inherit inefficiency in each of these practices. This inefficiency is of the same nature as inefficiency of Disaster Recovery Planning. Why would someone invest in second data center, backups, etc.? Sorry for one of those “blindly dumb questions”. Just consider the expense and impact on the business a large outsourcing initiative gone sour could cause.

Methodology. There are many best practices that apply to the methodology and/or the process of product / service development which also contributes to building DOM. Using software development lifecycle (SDLC) as an example I would like to point out just a few:

  • Project Management Office and many PMBOK style project management techniques
  • Pragmatic approach to documentation – producing just enough of it
  • Templates and style guidelines across all development artifacts, e.g. naming conventions
  • Automated Build & Deploy, Continues Integration and QA Automation
  • Many techniques from agile methodologies such as Test Driven Development
  • Comprehensive for SDLC management such as requirements management tools
  • Wiki, MS Sharepoint, and other project collaboration and knowledge management tools

This list in a large degree falls out of the scope of this blog as it relates more to building solid sustainable software development process independently from outsourcing. I will cover some of the most important elements of it in a separate post(s).

Infrastructure. Similar to the methodology above there are many best practices that apply to creating efficient infrastructure for supporting outsourced activities that also cater well to DOM. And similar to the list above it in a large degree falls out of the scope of this blog. I will cover some of the most important elements of building outsourcing infrastructure in a separate post(s).

December 16, 2008 Posted by | Managing Offshore Engagements | , | 1 Comment

Disposable Outsourcing: Caveat Emptor

As any other outsourcing model Disposable Outsourcing has its pros and cons and there are a few caveats worth discussing. Probably the most important one is a role of intermediary.

First, intermediary is not mandatory it is one of the best practices. There are a few tangible benefits that middleman offers here, the most important being isolation: Establishing working relationship with each vendor is a unique process, take for example MSA, the likelihood is it will be dramatically different from one vendor to another, and even if you use your own template the chances are you would have to negotiate on different clauses. There are plenty of other activities such as setting up environment, associate interviewing / screening, security, etc. that would require a significant investment. Using intermediary shields you from many of those. Isn’t it very similar to using some of well-known design patterns (adapter, façade)?

Another important reason for having the intermediary is a conflict of interests: It is unreasonable to expect that a vendor would make itself dispensable, as a matter of fact most of outsourcing companies are known for being extremely skilled in making themselves indispensable. Intermediary specifically charged with a task of enabling DOM has a responsibility and vested interest in making it happened.

There are more reasons I’ll mention just one more– intermediary is critical in supporting you through the offshore enablement and transition. These activities even with help of the third party are very challenging. In many cases that support alone justifies using a third party.

Now back to the caveat: Finding a good intermediary is absolutely critical for making DOM work and it is not at all easy. There are a few big names in the industry which play this role, in particular IBM that offers resources from smaller companies all over the world via its outsourcing wing. In a large degree it appears to be the best possible combination, unfortunately it comes with IBM price tag, as well as with many liabilities of a large company. Finding a properly sized, reliable and competent intermediary is the most significant challenge of the model.

In case you can not find a good intermediary the best approach is to build the intermediary team in-house. That could be less expensive than using 3rd party. The main challenge would be finding people with appropriate skill set, experience and knowledge. Another challenge would be setting up the group in a way that it has the authority and flexibility to do the right thing.

Another caveat of the model is a very significant challenge of creating the processes and procedures that would enable DOM. That is especially serious challenge for small to mid-sized companies and companies with low maturity of the processes in CMMI or ISO sense. I will cover the main dimensions and steps of what it mean “get it right” in a separate post. To some degree the intermediary can be a great help in this process yet still the bulk of the load falls on the customer.

One more important caveat or should I say trap associated with DOM is complacency. As I mentioned running DOM creates positive energy, has many benefits, and gets vendor to perform better. So inevitably you see the vendor as a solid partner, not someone who ever needs to be replaced… and the model starts to deteriorate: cutting corners gets more aggressive, little issues accumulate (entropy always increases), and before you know you are tethered to the vendor and eventually at their mercy. The disposability is gone along with its benefits and the only thing you have left is a higher cost of the resources that you could have got in the first place. Again, to some degree the intermediary can be a great help in preventing this from happening yet still the bulk of the load falls on you.

December 16, 2008 Posted by | Managing Offshore Engagements | , | 2 Comments

   

Follow

Get every new post delivered to your Inbox.

Join 25 other followers