In the previous few posts (see last post)on Managing the transition of Managed Services, we looked at a few issues that you have to consider when you are thinking of transitioning managed services to a new organisation.
- what are the key things to consider to ensure that the services you are transitioning are the right ones,
- the factors to look for in the new organisation to ensure that they are the right organisation for you,
- how you can manage the knowledge management and knowledge transfer from the old organisation to the new
- the interfaces you need to establish between the new organisation to your organisation and to other organisations and stakeholders.
Picture Source: glasbergen.com
In this post we will look at the structures you need to establish to manage the transitioned service and the risks associated with the the transition.
There are two key logical structures that need to be established. One is the structure that will ensure that the transition has happened properly and the new organisation is delivering consistently to standard. The other is the structure to oversee the ongoing performance of the organisation.
The transition oversight mechanism is very critical. This is the structure that ensures that all that is required in the transition is accomplished (all that we have talked about in our posts!)
There should be a Program Management Office that will ensure that the transition manager and the Program Manager get the required support.
Risks associated with the transition and mitigating factors
There are four broad kinds of risks that you should cater for in a transition.
1. Cultural Risks 2. Skills Risks 3. Legal Risks and 4. Business Continuity Risks.
Let us look at these one by one.
You are used to a particular culture (work culture, social culture etc.) in your current organisation. The culture in the new organisation may be completely different.
The main risk you face is that you (and your team and users) expect that the same culture would be carried forward in the new arrangement. This may be a wrong assumption.
For example, staff from organisations in Latin America may end their emails with “hugs and kisses.” This may be a bit embarrassing for British or American staff and they may take umbrage at this.
There are also cultural differences in sticking to time (many a time, people from South Asian countries are late for meetings), giving respect to seniors (people from South Asia are very deferential to senior staff whereas Americans and British are not), etc.
There are also nuances of disagreement. People from the East may not outright come and tell you that they disagree with you. They may sugar-coat their sentences with pretty things.
In my previous organisation, we had two outsourced units: one in India and one in UK. Many a time we found that discussions between them were lost in a sea of nuances. The project manager of the Indian organisation told me: “that X (of the British organisation) is very rude”. But, actually, the British fella was just being open and forthright.
You need to make sure that you are aware of some of these cultural differences and make sure that you cater to these differences.
It may be a good idea to have a class or a session where you bring your staff and users up-to-date with some of these differences.
If the new organisation has had the need to transfer some people under TUPE, there could be a big cultural struggle.
This is something that need to have been catered to at the due diligence stage. Do the staff of the new organisation have adequate skills to execute the project?
Many a time there are certain specific skills required for maintaining the system under consideration, which the new team may lack. For example, knowledge of certain interfaces in, say, Sharepoint.
When we transitioned our systems we found that though the new team did have the required technical skills, they did not have the required communication skills.
Communication skills are critical, especially if they have to talk to your users.
One way of mitigating this risk is to be ready to hire these skills from an oustide third party temporarily should the need arise.
First of all, make sure that the new organisation has proper licenses for the software and systems that they are using to maintain your systems.
In our previous organisation, we got into a pickle because during a audit by a large software house it was found that the out-sourcer did not have proper licenses for a product.
They pointed to our contract where it said that we were responsible for procuring all licenses. It was only our reputation that saved the day. We escaped without having to pay any fine.
There may be requirements by law in the new country for TUPE or its equivalent. This means that you may need to ensure that the new organisation takes on any staff of the old organisation that may have been affected by the transfer. There may be also other legal requirements which you need to carefully consider.
Remember ignorance of the law is not an excuse!
Business Continuity Risks
It is critical that you make sure that this risk is carefully considered and covered. You need to make sure that your business needs are not affected. You need to plant your feet firmly in the new organisation before letting go of the old!
One area that can fall between the cracks are software code stored in version control software. You may need to ensure that all versions are transferred.
In the next and last post in this series, we will look at your organisation’s readiness for the transition, change management and the transition process / project.