Picture Source: icomm.com.au
There are various reasons why you would want to transition your IT and / or software services to a managed services organisation (or from one managed services organisation to another). Some of the reasons could be:
- Competitive advantage
- Cost savings and capital savings
- Better service level requirements than that the current organisation can offer
- Legal and / or political compulsions
- Ease of management
- Access to higher levels of skills
- Requirement of implementing new technologies
- Need to concentrate on core business
- Security compulsions
This post looks at a few things that you, as the program manager of your organisation’s managed services, should concentrate on if and when you decide to transition managed services from one organisation to another (or, indeed, from your organisation to a managed services organisation).
There are nine dimensions that you should look at in such a scenario. These nine are:
- The services to be transitioned
- The organisation you are transitioning to
- The knowledge transfer from the old organisation to the new
- Interfaces from the new organisation to your organisation and to other organisations
- Structure to manage your new managed service.
- Risks associated with the transition and mitigating factors
- Your organisation’s readiness for the transition
- Change management
- The transition process / project
In the following posts I propose to examine these dimensions one by one, and based on my experience transitioning systems as CIO of a large international NGO (working in around 50 countries), throw open some discussion points and offer some pointers to what each transition program manager should be aware of while taking on one such a transition.
These ideas applicable to client as well as service provider: These thoughts and ideas are applicable both to the program manager of the client organisation as well as the program manager of the organisation to which the transition is being made. Of course, these two individuals may be looking at these ideas from slightly different points of view.
We would like to hear your inputs and feedback and your suggestions to make the transition of managed services successful.
1. The services to be transitioned
The first step in a transition process is to decide what needs to be transitioned and why.
Systems providing competitive advantage: If one of the key considerations for going for managed services (or changing provider) is competitive advantage, then you need to decide which are the key applications or systems that should provide this key competitive advantage and is now not doing so. For example:
- your sales website needs constant changes to meet up with new products and sales approaches and your current application maintenance team is unable to respond to the urgency of your demands on them to achieve this
- your customer-habits mining system requires vast amounts of ever-increasing storage and your current IT provider (or in house IT set-up) is not able to respond to this storage increase need
In these case you need to look very quickly at a transition to an organisation that can provide these urgent responses for these systems.
Problem systems: Are managing some of your applications or IT set-up becoming a headache for your top management? Are there constant escalations from for IT groups or software services groups to your top management committee that they are spending an inordinate amount of time trying to solve IT issues? Is this making the management take their eyes off the core business ball? This is clearly a signal that some of these systems need to be transitioned to a more efficient organisation who will take on result-based responsibility for them.
Systems needing technology upgrade / change: There are situations where you find that your systems need to change or upgrade technology to meet environmental changes over which you have no control. For example, if the database provider changes certain interfaces in the new version of the database and you have (unfortunately) used certain open source interfaces that won’t work with the new database, you may need to go in for an overhaul of your system. And you may not have the bandwidth to do this within your current set-up.
Systems having consistent quality issues: If, after study, you find that these issues cannot be sorted out within the current setup, then it is time to move on.
The reasons we, in my previous organisation, decided to move our setup to managed services were:
- we felt that the IT group should be spending more time with front-line departments understanding needs rather than concentrating on providing support
- we felt that going forward we did not have the skill base or the bandwidth to look after our key systems that needed to undergo constant improvements
- day-to-day support of systems in countries in different time zones was becoming a challenge for in-house support group
- people management of IT teams was becoming challenging in situations where there were spikes and falls in work load.
Systems to be excluded: Another key thing to work out is whether there are certain systems that need to be positively excluded from the transition. These may include systems that are highly sensitive (like those with patented algorithms or processes) that you don’t want to be exposed outside, politically and / or business sensitive systems like systems tracking, say, tax frauds, systems that are legally required to be managed in a particular fashion, like systems containing data about customers etc.
In my previous organisation, we excluded systems containing customer details from transition.
Due diligence: Once it is clear what needs to be transitioned, a thorough appraisal of the systems needs to be done. A detailed due diligence on the scope of work and specific areas to be transitioned needs to be done looking at the technologies, the architecture, the databases, the algorithms and database architecture. You would also want to make sure that you are taking care of any other systems that may be affected by this move. This may also be a good opportunity to look at implementing some of the improvements you always wanted to do but could not due to various reasons. You may also want to look at the IT road-map to see if there are changes needed.
Of course, there are various other elements that may be peculiar to your organisation that you may need to consider before deciding what to transition.
In the next post in this series we will look at what you should look for in the organisation you are transitioning to.
