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.
- Intermediary. Putting a middleman in between your company in vendor(s) offers many benefits that I covered in Disposable Outsourcing: Caveat Emptor .
- 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).