The objective of Disposable Outsourcing Model (DOM… and it has nothing to do with XML) is minimizing risks associated with outsourced elements of the engagement. The idea is quite simple: design the engagement model in a way that the offshore partner could be quickly replaced, say in a matter of weeks, without significant impact to the engagement. Plug and play so to say.
That is of course is easier said than done. However every step towards DOM is a step towards reducing risk. DOM positioning also promotes much smoother execution of the contract, cleaner transition between phases, uneventful termination, etc. In a large degree having a DOM mind set pushes you to do a lot of things right and that positively affects your projects far beyond outsourcing components. Since the initial introduction to the concept I have been perfecting my DOM approach and finding its multiple benefits along the way.
Anyway, let me start with an example of DOM implementation in my company: About two years ago I decided to build a small QA team on DOM basis. I started with defining the objective of the project and parameters of what DOM would mean. In a few words my position was following:
- I am open to outsource ~10 FTE in QA field under Classic Augmentation model.
- I do not care where the services are coming from. As a matter of fact I am not particular interested in specifics of the companies that would provide the services.
- I do care about the quality of individual contributors and quality of service they provide.
- In case I dislike someone I want him/her to be taken of the project immediately. In case offshore team fails to deliver the quality of service I want them to be replaced in a very short time.
- I have clear understanding of rates that I am prepared to pay for these services; and I am not about to consider any early termination penalties / etc.
The list of my “wants” (just a bit longer than the list above) did not seem ridiculous – I was not planning on getting rid of anyone just because of mood swings. However, realistically speaking, there were not too many companies in the world that would accept it. So the approach was to use an intermediate party that would take the contract, would not be invested in specific resources and could shield me from all the issues I did not want to deal with. Finding such a partner turned out to be not a complex task. A few months later I negotiated and signed a contract with a company which would act as an intermediary between my team and offshore provider(s). My partner would take on the risks / liabilities of maintaining the relationship, dealing with sourcing and termination, etc.
A few weeks later I was interviewing teams in China, India, Vietnam, Uruguay, etc. A few weeks later I settled a team. And we moved on.
At this point the main challenge was building a process of making offshore team dispensable. Of course I was not planning to get rid of the team, I just had to be prepared to it and be able to execute it well. That turned out to be a fairly involved exercise as we had to make sure that everything we do with the team to get them enabled / ramped up on our product is documented. Of course we made producing the documentation an integral part of the process itself and tasked the offshore team with it. We did the same with developing test plans, all SOPs, etc. The mindset “what if this partner is no longer here tomorrow?” was pushing us to do things right. My partner’s oversight and governance was an additional enforcement mechanism – basically keeping my team and the offshore provider honest. My partner was deeply vested in getting it right as the cost of the transition would go straight out of their pocket.
Shortly after start of our initial QA DOM exercise we kicked off another team working on development project under Project-based Augmentation model.
We first realized the benefits of the approach when facing inevitable turnover and “hiring mistakes”. It was surprising how quickly we were able to add new members to the team to replace losses or poor performers.
Our biggest pay off came in when we had to replace one of the offshore teams, it was by all means a non-event. Well, far not everything went right, but comparing to my previous experiences, the difference was dramatic.
While two of our offshore teams were operating under DOM paradigm we had another two teams involved in multiple aspects of our SDLC working under similar augmentation models without DOM ingredient. That gave me some limited material for the comparison / analysis of the approach. Here are a few interesting observations characterizing our DOM experience:
- Offshore vendor was constantly on their toes; that is of course a double-edge sword; our assessment that it was much more positive than negative.
- The communications in general were better with the team working under DOM model. The number of project conflicts and issues to be resolved between onsite and offshore teams was substantially lower under DOM model.
- DOM mindset turned out to be contagious in a good sense; attention to documenting the processes and appreciation of its value went up across the team including parts of the organization that had little to do with outsourcing.
- DOM notably increased our overhead in the initial stage of the project (comparing to a regular outsourcing model); the overhead went substantially down after ~3 months. Comparing that to a regular project I would say that overhead was lower under DOM over long time.
- Attitude toward our DOM team was substantially better than towards the team operating under regular Classic Augmentation. In particular there was substantially less apprehension towards offshore team members from the onsite employees, and I would say higher sense of security.
- Interestingly enough we found that the offshore team overtime started seeing some benefits of the DOM and did not particular perceived it as making them disposable; to some degree it came down to doing things right.
There were a few things that fall in category of cons of the DOM. Here are the most significant:
- Very significant increase of the overhead during initialization of the project.
- Cost of the resources / rates are higher given other things being equal.
- Working with / through intermediary could be a real pain in the neck.
I would say the success and value of benefits that could be realized from the DOM model depends in a very high degree on the intermediary. Finding a good company to play that role is not a trivial exercise. There are a few other challenges worth discussing on the DOM and that deserves a stand alone post…