I said in my Context of Outsourcing post that outsourcing is open and big topic. I would like to highlight the key rules as I see them. Once again, there is no one size fits all solution. Every IT Organization who wants to jump into the outsourcing band wagon will have different view based on the context such as
· Industry,
· Technology footprint,
· scope,
· size,
· current level of efficiency,
· productivity,
· service levels
Unfortunately, you can not outsource the task/decision, of what, how, when, why to outsource. The reason for that is every business is run by the people who have (form) their idea of how best to run it. IT Organization within the business has a lot more views of the people. Each IT organization have portfolio of applications developed over a period of time in different ways and different circumstances. In today’s industry, business gets sold and merged, CIO’s keep changing, which makes each IT portfolio/footprint almost unique like a signature. As guidance, there is a lot available in IT market place such as general trend, analysis, reports, third party advice. When it comes to outsourcing, CIO/IT Organization has to take his/her own decision/roadmap as it is quite involved and almost like a personal choice
I have listed my own choice of TOP 5 rules below:
1 Cost Should Never Be The Only Factor:
IT outsourcing only to save cost is not likely to succeed as there is lot of management efforts and money to put in up-front to design a model to work for each IT shop. It is not worth the management effort if the idea of behind outsourcing is ‘your mess for less’. To me IT outsourcing it like re-organization, there is a lot of consideration. The biggest one which most often is not considered is ‘people’ factor. Unfortunately automation level in most IT organization is quite low; hence the service delivery of IT organization is fully dependent on the people. There are other factors such as process, tools, technology, measurement, management to name a few. When IT brings a new entity (read people) to participate in end-to-end service delivery, it has a lot of depend on working together. ‘One Team’ approach is already key-trend/buzz word in IT outsourcing. However, it much more than just a buzz-word, it needs adoption depending what, why, how one is outsourcing. The level of team integration will vary quite lot depending on just you are outsourcing. For example, SAP application maintenance may be simpler exercise compared to be-spoke legacy application with a number of web-based front-end systems. Even in SAP situation, level of customization, availability of system, number of users, number of interfaces will always be different for each outsourcing context. That is where, inter-dependency, risks, end-to-end productivity, OLA play more vital role than the cost in making outsourcing a success.
2. Do Your Home Work
IT Outsourcing is not one-off decision. Even in the days of doubt-sourcing and today, it is a strategic decision and hence it is long-term in nature. So there is no rushing to it. It is not simply choosing a vendor or service provider which is what most early adopters of outsourcing thought it was. They all have now learnt a hard way that it does not work that way. The trouble is those who failed if they do not continue with outsourcing (i.e. if they in-source) they may be making bigger mistake. Outsourcing failure is never the service provider’s failure it is always the buyer’s failure. The service provider may contribute to the failure. The key responsibility to make it (Outsourcing) work always lies with the buyer (IT organization). You can never transfer the responsibility to make it work completely to the service provider. The ability to team up with the vendor is the key to the success. For all such failed cases, if you look back, the buyer of IT outsourcing has not done enough home work before embarking upon outsourcing. Once again the home work will mean different things to different people (IT Org.) such as due-diligence, involving HR, managing risk, choosing the right candidate project first, evaluating vendor’s ability so and so forth.
3. Define the Big-picture/Use Defined Process
As I mentioned in my Context of Outsourcing, over a period of time ( few decades) each IT organization has been always trying to deliver new functionality some how or the other. There always has been shortage of people in terms right quantity or right quality. Once any new application and new change goes live, there is no looking back. No one completely re-writes an existing and running application. The level of document is dependent on overall IT management, processes followed but more than the desperateness of the team to go-live where the documentation is always secondary if you are missing the deadlines.
The trouble with software development there is no right estimation. Hence all sorts of problem crops either before the application hits the ground or after that. I remember and I liked the statement from Roger Pressman in his book of Software Engineering, “The best way to do the estimate of a software development project is to do it”. It takes what it takes is the answer. That is one of the key reasons, IT industry has not bothered to develop any set of standardized estimation methodologies/ techniques. The whole process is so people-centric/dependent.
With these conditions, one of the first things to do is to define the existing processes which will help the buyer in communications and teaming up with the service provider. In fact, the whole communication with the service provider will become much more effective and specific if you can point to specific aspect of running the IT shop. For example, a simple thing like the testing is conducted so many different ways in each IT organization For example, few IT organizations may have testing as a separate unit/service within IT. Some will have different testing process based on the delivery platform such as main-frame in one-end of the simplicity and an intricate Web applications with a number of technologies used as high as 20 at other-end.The service provider being an outsider (even if an incumbent vendor) can not relate to the complexity of internal working unless it is properly defined and explained. It is obvious that if the service provider does not understand/relate to the big picture, it will not be able to deliver the results even if they try the best. Please note that in most cases, the service provider has a lot of tools, methodology, domain knowledge but what is usually missing the relevance to the buyer’s context.
4. Relationship is the Key
Over a period of time, outsourcing has come a long-way. There is number of measures which are in place such as SLA. However, a lot of occasions, there is no existing service level defined between business and IT. When the buyer is teaming up / partnering with the service provider to deliver the desired level of service to the business, it sounds as if the buyer is telling the service provider ‘Never mind, we (IT org) never had any SLA with business but I want you to adhere to a strict SLA’.
I am not suggesting that
SLA’s are not needed but it needs to be appreciated by the service provider which can only happen by building a true partnering relationship. Otherwise, as it always happens for each
SLA, the smart service providers if they doubt the intentions will include assumptions and /or OLA in the contract which will nullify the SLAs.
5. Identify the Risks Early
As I said earlier, IT outsourcing engagement is like a re-organization and hence it is a major change for both business and IT. With any change, there are risks associated. To me, most of the risks are buyers risk there is only few risks which are service provider’s risk. If the outsourcing deal fails service provider at worst does not get paid or is thrown out. It is the buyer’s business which is hit by the failure depending on the impact which can varying from loss of couple ( or hundreds) of millions dollars, to one missed opportunity for the business or it can also be an irreparable damage to the reputation in the market such as National Health Service of UK (NHS) failure in IT programme NPfIT.
In a lot of outsourcing RFP, I have seen the buyer expects the service provider to identify the risks. This can only serve the purpose of assessing the capability of the service provider. If the buyer does not want the failure as an option, the risks should be identified upfront .The earlier it is done it better for the success of the outsourcing deal. Once identified, the risk mitigation plan can always be jointly managed by the buyer and service provider. Once again the other factors such as relationship come into play in mitigating the risk. Transferring the complete ownership of risk mitigation to the service provider is not likely to be very effective.