What are the best methods of knowledge transfer?
What kinds of documentation should be expected?
What activities should take place before and after handover, both by the external party and ourselves?
closed as not a real question by Robert Harvey, gnat, pdr, BЈовић, GlenH7 Nov 27 '12 at 16:06
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. If this question can be reworded to fit the rules in the help center, please edit the question.
The answer to this depends on a lot of different things e.g.:
(Note: this is by no means a formal list, nor is it exhaustive - just my suggestions, Ive so far managed one of these kinds of transitions, but the transition was planned before development started - which as DaveNay points out, makes the process much easier)
The first four questions deal with your ability to resource and continue to maintain the project. Obviously you need to have the skills and available resources to take the project on, so you will need to estimate the size of the project and to understand any skill gaps. You will need to figure out how much work will be required to maintain this project and deliver any agreed functionality. You need to include adequate time for training and upskilling. Have plenty of slack in the schedule, as nearer the end of the transition the vendor will have less motiviation to help you out.
To be able to assess the size of the job, you will need to get the guys who will be working on it looking at the code base as soon as possible. Depending on the quality of the code the amount of effort to onboard can vary dramatically. Make sure you get the input of the developers and consider it carefully. Some companies deliberatly make their code difficult to understand so that it is hard to migrate away from them.
In some projects you may find you need a specialist skill, possibly even one that only people working at the third party have. If this is the case (and depending on your relationship with the vendor) you may want to arrange a consultant from the vendor to work in house for 6 months to a year. Even if this is not the case, it is possibly a good strategy to go with, the vendor will not completely lose revenue from your company, and you will more effectively be able to train your team up.
Technology & Archictecture Assessment
Depending on the type and architecture of project, you will need to understand what tech requirements there are. Do you need to purchase your own servers? Are there any other hardware or software requirements, e.g. do you need software licenses, additional middleware installations. There is potentially a long list of items here that you need to consider. Go through the project with a fine tooth comb, find out every hardware and software dependency, and make a check list of each. Remember that you may need to consider things like:
The next stage is to assess the project itself. Get a list of all the features that are supposed to have been implemented by the vendor, make sure you have a record of any bugs/issues or incomplete features. Submit this to the vendor and agree the final list of what they will do. This is more from a value for money standpoint - if you have paid for them you want to make sure they are done. If the relationship with the vendor is poor, or you dont have confidence in their abilities you may want to do the work yourself - but you should still compile the list and make sure your management is aware of the effort required to complete the required features or fix all the issues.
Managing the transition
You ideally want to work in parallel during the transition period. You want a decent amount of overlap time, but not too long so you dont lose the sense of urgency - how long that is depends on the size of the project, for something small 1 month should be enough, something large 6 months.
You should start the transition with the vendor doing most of the work, and gradually have your people take issues on. By the end all issues should be done by your team, with the vendor only providing support. Each developer on your team should have someone in the vendor's company who they can call to help them with issues. Try to make sure that the issues being worked on touch as many parts of the system as possible. Ive seen internal handovers where developers spend weeks 'looking into' a code base to understand it, but at the end of the period don't really gain anything more than a vague understanding of how the system fits together. Developers need to be writing or changing code to really understand the in's and out's of a system.
You will need to manage three different kinds of relationships:
In terms of managing the vendor, you need to be very much on top of everything. Remember that unless they have a good chance of repeat business, or referrals, they have little incentive to make the process easy for you. Some companies will make the process very difficult.
Have one point of contact inside the vendor who has the authority to make decisions and who you can go to with any problems/issues - everyone should be in agreement that this person is responsible for ensuring a smooth transition. Make sure you get agreements up front from the vendor as to what they will and will not do, and make sure that what you agree is fixed fee. Do not agree to paying a particular rate for an unspecified amount of time, or the vendor will drag their heels. Make it clear that the number one priority for them is to transfer knowledge to your team. If the developers on their team are not forthcoming with help, or insist on doing things themselves instead of training your guys to do it, bring it up immediately with your contact.
Schedule an initial meeting/call with the development teams in both companies making it clear exactly what is expected by everyone. Schedule weekly calls (daily as the end of the handover nears), go through every issue, bug, feature and the status and make sure its on schedule.
The amount of communication with users/customers needed will depend on the amount of contact that the vendor has with them. If there is no direct contact, you should still let customers/users know what is happening, and warn them that it may lead to delays, or other issues during the transition. If there is direct contact you will need a seperate process to manage that, e.g. if they provide user support, you will also have to ensure you have the resources, training etc to do this.
You will also need to keep your management team aware of everything that is going on. If you dont, and issues come up leading to delays or disruption, the blame will fall on you and your team. Always manage upwards and be as transparent as possible. Send reports regularly to your managers, distribute them as far up as you can. Make sure the reports are concise and clear, with an overall status at the top and any issues highlighted in red (most senior managers will not read through a lot of detail). If there are issues with with the vendor, make sure that it comes through in the report. Do not try to cover up problems in the hopes that they will in time go away - chances are they wont and it will reflect badly on you.
Make sure you are aware of any legal or compliance issues that you need to be, e.g. data protection and privacy laws, regulatory reporting, auditing, Sarbanes-Oxley etc. If the project you take over has any such requirements and you do not comply, the penalties can be severe.