The pressure to reduce costs and the availability of engineering talent in low-cost locations is pushing several organizations to outsource their product development. The modus-operandi and interaction patterns in an outsourcing situation is a little different from that resulting from off-shoring. The primary difference stems from the latter being a geographic extension of the same organization while the former results in dealing with a different legal entity. This inherent difference in interaction standings require a different focus in creating and writing requirements and the development process.
Creation of better release plans: Organizations offshoring must realize upfront that the cost against the potential savings is the sacrifice of flexibility. Changing of requirements and even tweaking of a feature will result in a change request generated that will have cost (for outsourcer) and revenue (for vendor) ramification. It is therefore imparitive that a very well defined release plan be created and adhered to.
Devlish Details: Organizations that have product management and engineering very well integrated as a team need not spend hours producing pristine requirements. However, in a situation where the requirements will be thrown over a wall to land a few thousand miles away it is a necessity to create detailed requirements. Interestingly, several organizations take this as an opportunity to inculcate a discipline of writing good Use Cases from their product managers and business analysts.
Work out the translator math: Most vendor companies employ business analysts (or those who are euphemistically called “functional experts”) in development projects. These resources come at a higher cost than the engineers. Primary function of this team is to translate the requirements from the outsourcing firm to the vendor. While at first glance this may look redundant, it is not – mainly because of the asynchronous nature of communication that the engagement creates. This layer may take some burden off from the firm outsouricng in the area of creating detailed requirements. It is important to work out the marginal cost between adding a business analyst from the vendor vis-a-vis having a product manager from the outsourcer doing the same task.
Provide Wireframes: Creation of wireframes – either low fidelity ones or high fidelity prototypes – fall in the gray area between product management and engineering. In an outsourcing situation bring this back into the fold of the outsourcer. It is important – even if in-house engineers are required – that the vendor be provided with at least a low fidelity prototype of what is desired. This becomes a part of the requirement.
Cleanup the house: Many products have internal dependecies that must contribute towards fruition of a release. These must be handled and resolved by the firm that is outsourcing. It is not sufficient to merely identify these dependencies. Vendor organizations will never completely own up to these ones.
Two processes cannot work: Outsourcing vendors are mostly all certified for processes like CMM, ISO etc. While this is a good marketing qualification for the vendor, it may not necessarily translate into value for the organization outsourcing product development. It is always prudent to ask the vendor that they adopt any existing process that the outsourcer may already have. Processes clashing with each other is a much more avoidable situation than personalities clashing.
It is important to keep in mind that outsourcing (or even offshoring) is not a free lunch. And that the benefits are not equal to the cost arbitrage. The benefits are significant but they should be adjusted against the implicit costs of sending work that would have been done across the hallway rather than somewhere a few thousand miles away.