Change management

Change management is a double-edged sword when applied in outsourcing. If an outsourcing company is willing to track its performance the first step would consist of the definition of critical success factors and related key performance indicators. Then most probably there are some changes that need to be implemented on the ground in order to be able to collect useful data. In a service model outsourcing, the production development process itself is subject to changes from a client to another. When an outsourcing provider fails to implement the process changes required by the clients then that would jeopardize his commitments, service level agreements as well as his ability to operate efficiently on low cost. On the other hand implementing those changes in a cost effective way would increase the credibility of the outsourcing vendor as well as his ability to adapt in a timely manner.

Similarity with OOP

Scalability is another factor that plays an important role in change management. In Software engineering (Object Oriented Programming/ Inheritance) The object itself does not contain the business implementation; a software engineer can change the behavior of many objects by simply modifying their class or its root. When you implement a change affecting 4 resources, make sure that the same change is easily applicable when it affects 40 resources. Otherwise it would be better to invest the time into finding the right method to apply your changes.

Starting point

It is very important to identify 3 things when implementing a change:

1. What are the areas that you cannot touch?
2. What is the affected area by your change?
3. What are the subsets, within your affected area, where you do not have control over it?

Points 1 and 3 cannot be included in your plan. Make sure that you list these areas with large fonts otherwise your chances to fail would be 10 times more than your chances to succeed. Once you identify your affected area and the subsets under your control, you should then isolate a case and apply your changes at project manager level not at a team level. Make sure that only your PM is concerned by the first change. Once your PM digests the changes provide him/her the tools that allow him/her to implement scalable changes to his team. Change the content and not the concept; if your team is used to send daily emails then do NOT stop emails and use other collaboration tool but simply standardize the content of emails so you or your PM can easily extract information. This change would be easily accepted by your team because it does not require them to ramp up on a new tool. You can compare it to asking a left-handed to write with his right hand while he surely prefers to write whatever you ask him with his left hand than writing his name with his right hand (I know that because I am a left-handed!)…Simply minimize the feeling of a change across your team. Once you succeed implementing your strategy in 1 team, you should take lessons, adjust your plans and your tools in order to be able to implement a scalable solution at the level of your company using the same strategy that starts from Project managers down to team members.

Decision making workshops

Core changes require a lot more effort than simple data collection process changes. An innovative way would consist of organizing decision making workshops where your teams members play the role of decision makers in your company, propose the problem and let them converge by themselves to the required change modification. Group discussions are extremely important in that case and they should be guided by a smart person who really knows how to be a lead collaborator than a guide or a teacher.