The Business Alchemist recognises that outsourcing makes sense for many organisations. Either the skills are lacking in-house, or the infrequency and nature of certain types of work makes maintaining a full time capability financially unviable.
A number of these outsourcing customer organisations however struggle to define how outsourcing can work for them, what activities in the lifecycle they do themselves, what they provide as input to their outsourcing supplier, what activities they perform together and then what the supplier is left to perform.
A question about outsourcing was raised during a recent workshop, and as I turned back to the flipchart to begin sketching something I had one of those eureka moments. The question was along the lines of "how do you work out what products to provide your outsourcing supplier with and then what do you do?" and there before me was the v-model diagram I had drawn and explained for a different purpose shortly before.
For those not familiar with the v-model it is illustrated below (there are many variants but we'll use a version consistent with various BCS/ISEB certifications). It's an extension of a waterfall/linear model developed initially by the testing community to describe how the layers of artifacts defined through the lifecycle are verified and tested. So for example the business requirements are tested using User Acceptance Testing, the Program specifications using Unit testing and so on.
My eureka moment was realising that the v-model was an ideal start point for defining the relationship between the outsourcing customer and supplier. I've dealt with many outsourcing parties on both sides of the relationship over the last decade and am aware that there is often confusion on both sides as to who is responsible for what, either with activities being duplicated or sometimes missed out.
Establishing the primary contract boundary
The first thing to do as an outsourcing customer is to decide to which level you have the capabilities to perform the activities and draw a line at that point. Let's say that a mythical company, Kustoma, employs Business analysts that are comfortable drawing up business requirements but are not very technically minded. Kustoma has IT support staff but they lack development design skills but can help define certain technical requirements in order to ensure the proposed system is compatible with their existing hardware and software (precisely the kind of technical constraint requirements that should be in a Business Requirements Document). Kustoma recognise that the key boundary between them and an outsourcer will be between the Business and System Requirements.
They understand that they will need to source a supplier to perform the rest, with their key verification activity being the User Acceptance Testing (UAT) at the end of the process.
For different organisations this point may be lower, and for some it may even sit right under the business case.
However simply handing over a Business Requirements Document and waiting for the delivered product to be able to perform UAT is clearly not a sensible approach. How can you validate the supplier's artifacts and ensure that they understand your requirements correctly yet alone handle change?
Zones of disclosure
There will need to be ongoing activities to ensure that the work their outsourcing supplier does is fit-for-purpose as defined by the BRD and that ultimately the Business Case still stacks up.
In Kustoma's case they have selected an outsourcing partner, Zuplia, who they have worked with before. Zuplia demonstrated that they are more than happy to work closely with Kustoma to ensure that they fully understand the requirements and can correctly estimate a value for the contract agreeable to both parties. In order to enable both parties to collaborate on managing quality Zuplia agree to workshop the Technical requirements and to share their Design specification. They are however protective of their technology and have limits to how much they are prepared to share drawing the limit above the Program Specification. Kustoma are also aware that a certain amount of disclosure is required on their part to support their requirements but they are not prepared to fully disclose the full contents of their business case as some of it is commercially sensitive.
So around the primary contract boundary they define in their terms of reference three zones: Kustoma's disclosure zone, a joint collaboration zone and Zupla's disclosure zone.
What these zones also allow both parties to do is to define the ongoing quality monitoring and checking touch-points and activities (see dotted arrows above) that will ensure that the customer receives a fit-for-purpose product that they are willing to pay for and potentially carry the relationship forward to the next project.
Degrees of trust
Initially I was tempted to refer to the zones described above as "De-militarized zones"; but that suggests conflict and the potential for a "no man's land" gap.
Ultimately, although both parties have their own commercial interests at the heart of their activities, in an outsourcing relationship there should exist a significant degree of trust represented by relatively broad layers of open collaboration and disclosure where the project can breathe, so I prefer to call this collection of layers the "Atmosphere of Trust".