No company does everything themselves they all buy some services and perform others. There is nothing intrinsically peculiar about IT outsourcing; what catches imagination here is the scale of the deals, the emotions concerning off-shoring, and the spectacular failure of those deals which have turned nasty.
The motivation and context for outsourcing change, as do the technical conditions which enable it. It’s also likely that the recession will make companies reconsider their position, as they become more concerned with short term cost reduction (survival being the strategic goal) and quite what the consequences of the Satyam debacle will be have yet to be seen. There are, however, no more black or white decisions when sourcing than anywhere else.
For example, don’t be taken in by people peddling the concept of “Smartsourcing” as if it were something new and distinctive (not so subtly implying if you don’t buy it you’re dumb). The fact is that there is no single approach which can guarantee success (single sourcing, multi sourcing, keeping as much as possible in house and so on). Any smart approach will mean thinking long and hard about the real options (and this market will quickly punish stupidity). There are, in our experience, a few basic rules, but they are more about helping you to read the lie of the land, rather than an idiot-proof map.
In Differentis we’ve had quite a lot of experience of outsourcing, from both sides of the table, and would like to suggest some basic pointers which may help.
This month we are going to concentrate on the objectives of outsourcing, and we’ll look at some of the ways of achieving them next month.
Know what you want out of the arrangement
Be very clear what success looks like for you and make sure your suppliers know, and share, your views. A lack of alignment will show up quickly, but not quickly enough to disentangle the people, assets, and contracts without huge cost and effort. Multiple objectives are possible, but trade-offs are inevitable.
- If you want to focus on what is core, you will want a light touch in terms of management attention, so make sure you draw the service boundaries right
- If you want to force change you can’t make on your own, be clear how much control you are really handing over;
- If you are seeking a transformation of processes, culture, or technology be clear how much investment this will take (whoever is funding it) and that it will be very expensive to rethink later. Also do not underestimate what you have to do as part of the pact;
- If you need to get costs down put in the controls to ensure that extra demand doesn’t run away with any promised savings;
- If you need a cash injection (for asset purchase or to fund transformation) compare the implied cost of capital with the claimed cost advantages; outsourcers are not typically cheap banks.
Do not assume commodity means the same thing for everyone
Be clear about the difference between commodity and value-adding services, and do not define them in the abstract without reference to your specific circumstances. For example, what might suit a government department, where demand may be relatively predictable and tasks defined, may not suit a company whose staff utilise new technology to respond quickly to their customers’ needs in unpredictable ways. Providing a locked-down desktop in the one case may reduce cost and increase service quality but be extremely unhelpful in the other. Desktop support isn’t always a commodity; it depends what you do with the desktop.
Define the required outcomes and (try to) get the suppliers to agree to deliver them
Define the services or technical solutions in terms of what they have to achieve, not their technical constituents. There is a hierarchy of means-to-ends here, so choose carefully the level of description in the contract. Many SLAs only make sense to suppliers and not users of the services. What matters to users is likely to be things like getting goods out of the door fast, process efficiency (e.g. numbers of people involved), or customer satisfaction, not percentage availability of a server. Moreover, defining the outcomes places more risk -and more leeway- with the suppliers, and enables you to concentrate on value, not on the means. Agreeing an 8exhaustive list of technical requirements before contract can kill the process, as it will never be complete; therefore both parties need to know what the supplier is on the hook to deliver (an outcome!) or you’ll be at each other’s throats as soon as the first major deliverable falters.
Expect and plan for change over the life of the contract
Don’t just consider what happens in year 1; allow for significant change at any time over the term. It is certain that change will happen which no-one expected and for which the contract does not explicitly provide, so go beyond a general “agreement to agree” clause and lay down some conditions. Those companies who now need to recalibrate their contracts as a result of the recession will find it much easier if they had done this.