I often read a lot of bitter comments on news articles – such as this one – when a new IT outsourcing arrangement hits the press. The reader comments often appear to miss the whole point of outsourcing and in turn what could have been done to avoid it. I’ve always taken the approach the IT Outsourcing has value, isn’t in any way morally wrong, and is here to stay – so I’ve eventually learnt to understand it and therefore understand the opportunities in the industry.
Firstly, it’s important to understand that almost all cost savings provided by outsourcing are through increased visibility of spend and therefore more careful selection of which initiatives are pursued. It may be that certain outsourcing relationships offer access to specific capabilities, or that certain outsourcing relationships can be managed as a source of differentiation or innovation. But that’s not generally the value of outsourcing; that’s just outsourcing as a pillar to strategy and innovation management.
Outsourcing is often a last ditch effort to get costs – or visibility of costs – under control. It’s a recognition that portfolio management processes aren’t working, nobody fills out their timesheets, it’s very difficult to get IT departments to think in terms of business services or capabilities, it’s very hard to ensure documentation is kept up-to-date, and in general that mismanagement of IT has burnt out IT resources.
Outsourcing solves a number of these problems by simply putting a contract process in the middle of everything. Outsourcing basically means that in order to get anything done you need to procure a service – which means you have to justify the spend, assign it to cost codes, and be clear about the outcomes right up front. All of these things can be achieved without outsourcing but they simply aren’t. There isn’t enough discipline to do things consistently so the management team simply can’t run the IT department ‘like a business’ because they don’t know what is going on.
By putting a procurement process in the middle of everything it forces proper allocation of costs for everything. The outsourcing partner gets to choose between doing things for free, or being paid for it and thereby having to commit to certain outcomes and to be part of a managed procurement process which gives visibility of spend. Eventually, outsourcing partners decide they want to get paid for services. Eventually, things get better…
Unfortunately, being able to come to a contractual arrangement, to actually procure services, is a capability of the client organisation. It requires an ability to define outcomes, to cost and transfer risks as appropriate, and to perform service definition and orchestration. At the new finer granularity of the services to be procured the client organisation that has just outsourced may not have these capabilities.
So outsourcing arrangements suffer from an inability to come to contractual arrangements. And the reason they do is that they have never had to do those sort of contractual arrangements before. All of the portfolio management disciplines, solution and enterprise architecture processes, cost allocation, and even basic IT strategy process, haven’t been working. The fact that they weren’t working is the very reason the outsourcing had to occur. But they are still required in order to come to contract agreements once outsourcing is in place.
A common mistake is to try and roll-back the disipline in coming to contractual agreements. Because the supporting capabilities aren’t in place it’s very time consuming to come to agreements. The cost of spend visibility is seen as too high. But rolling back the requirements to come to contractual arrangements shouldn’t be the solution. Also, the contractual arrangements also allow the flexibility to procure ‘outcomes’ once the diciplines are in place to know what outcomes you actually want to procure.
In theory, you can avoid outsourcing by putting certain things in place to ensure full visibility of costs to the executive team. In theory, you can implement all of the portfolio management processes, enterprise architecture processes, cost allocation, etc and avoid the need to outsource at all. But in practice you can’t because there will always be comparative advantages in different countries / regions, and advances in communication and collaboration technologies that make off-shoring a valuable strategy. And while your company could build their own off-shore capabilities there are political and cultural considerations that make this a risky strategy. To off-shore you generally need to outsource.
So in the end, outsourcing is here to stay. The only thing you can do is understand how it delivers value so that you can understand how work is different in an outsourced environment. Here, the key messages to the ‘retained organisation’ are: things will change, new people will not have the same experience with your systems, new people will take longer as first. Most importantly, the message to the retained organisation is that for most people outsourcing isn’t actually for them – outsourcing is for the CFO or CEO.
The key message to outsourcing service provided is simple. Get much much better at providing the services you have been procured to provide.
There will be a number of new skills that you need to aquire when you first experience outsourcing. However, it’s worth learning them because this isn’t going away and some of them are skills you may have been missing for a long time.
Management, as a discipline, has a problem it can”t solve. It needs to coordinate separate but related activities caused by the division of labour. And it needs to be able to do this regardless of how labour is divided.
Project management, in particular, has this problem. I’ve said before that project management is a perfectly reasonable discipline as long as it doesn’t try to cross organisational boundaries. This is why project management is necessary but not sufficient in managing outsourcing.
Likewise, program management – which the discipline likes to define as the management of multiple related projects – isn’t really a separate discipline because of the scale of the work or the number of projects, it’s a separate discipline because multiple projects have multiple project managers.
Unfortunately, the accepted tenets of management simply do not scale. Multiple managers causes more problems than they solve – and therefore situations which require multiple managers need other practices to govern them.
The root of this problem is that ultimately, the discipline of management doesn’t in itself offer any useful advice on how to divide labour. It takes it as a given that labour is divided and then attempts to coordinate that.
Equally, managers – when you switch them on and give them responsibilities – tend to manage to those responsibilities. Good so far, but if the division of responsibilities isn’t right there is a problem. The problem might even get bigger if the managers are better.
But there are right and wrong ways to divide labour. Some activities are autonomous and some aren’t. Dividing management responsibilities and activities has its own additional challenges.
Only ‘architecture’ (which I define in this context as deliniated shared understanding) can offer any help in the actual division of labour. However, architecture must be domain specific. In order to determine correct/incorrect or efficient/inefficient divisions of labour it must take into account the domain and the required outcome.
(by the way, if you think a ‘strong management team’ solves this problem check out my article on ‘Management Teams as Cartels’)
There is no avoiding it. There is an overlap between some aspects of the MWT Model and what is increasingly called Multisourcing.
The Multisourcing dicipline really is beyond procurement, outsourcing, and supplier management. Multisourcing is both a strategy and a strategic capability of the client organisation. It is the end-to-end process of service definition and management, selection of who will perform services, decisions on where services will be performed, and the related governance and performance management.
Though in truth, the diciplines relating to Multisourcing can be relivant even to organisations which deliver services using predominately on-shore, in-house capabilities. This is where it relates most interestingly with the MWT Model and service-based management in general.
I have created a new blog category for posts relating to Multisourcing. This is such an important disicpline I would expect these would be of interest to anybody with an interest in the MWT Model.
If you’re already keen to learn I recommend Multisourcing: Moving Beyond Outsourcing to Achieve Growth And Agility.