About transferring project

How to understand that it is time to change a team?

In truth, primary thing that you should start with is your strategy and goal.

1. Planned reduction of expenses after the product have been released to production. For example, if you wanted to get the product as soon as possible, you have sufficient funds and you have hired a very professional team. After product launching process, probably you would like to overview your expenses, because the main work is done. But you should remember about support, in other words, make sure that it will continue to work as it should be. Paying for support its total value is not economically feasible, so it's a chance to receive a new arrangements or find another team. In this case, you can conclude with the current team a consulting agreement and contact them in developing critical functionality.


2. Quality degradation of software development, non-compliance with time arrangements. If you have noticed that with the full implementation of the arrangements from your side, the speed of development process has decreased, or quality has fallen. Mostly, typical reasons: leading developers can be transferred to another project, and they are replaced by people with less experience or less understanding of the specifics of the project; your top-of-the-range specialists on the project left the team; the contractor's management decided to increase marginality and replace your developers with others specialists with lower rate.

If it’s time, don’t be afraid of changing your system development team. If you think that the team you start with has great competences, understands your business and you are in a certain comfort zone. If you worried that there is no alternative. Just think about your current results and your cooperation with a team, weigh all the pros and cons and make your choice.

Transferring project

Well, you’ve decided to change your team. Do you remember what we have advised you at the beginning of the cooperation with previous team? You should start from organizing the maximum documentation of all the solutions and elements of the system.  If you succeeded in doing this, the project documentation will greatly simplify the introduction of the new team. Besides, the significant question will be: “Who is accessing data to source code and project documentation?”. If you have these accesses, then no questions asked. If  these accesses in the current team, then you need to arrange about documentation downloading, specifically:

• description of the web architecture and functional use of parts of the system
• descriptions of interaction protocols between system parts and external systems
• descriptions or process schemes
• descriptions or user story schemes

Even, if you have all the accesses, but you are extremely dissatisfied with the work of previous team, it’s not a reason to repudiate a claim of some work that they made for you. Apart from the fact, that it can spoil your karma as a whole, also it’s not very good from the point of view of business ethics. There is still a point: that you won’t be 100% ready for the system “surprises”. Your new team will need some time to learn all the system features, and by this time you can get unpleasant moments and blocked business, through some small issues that the previous team would correct it in a few minutes.

Due to this, it is important to split with developers on a good terms, in order to stay not as best friends, but at least in neutral relations.

What is important to do for a quiet and seamless introduction of a new team:

1. Give an opportunity to learn the existing documentation of the project and audit the code before they start their work on specific tasks;
2. Make an arrangement with the previous team about consulting services for a specific period (depends on the complexity of your project). During this period, you can involve your previous team to help in finding out the details of system activity, which are not described in the documentation;
3. Clearly agree with a new team according to the cooperation scheme: periodicity of payments, financial structure;
4. Plan together your further cooperation in software development process, or just explain your previous plan to developer if you do not change anything;
5. Don’t forget to take an active part in software development as a product owner.

Important! You must take into account that effectiveness of your new team can not be on 100% for the first couple of months, in comparison with the previous one, because they will need some time to sort out all algorithms and system processes which were created by other people.

Now you are ready for the transferring.

Good luck in business and constructive cooperation with IT companies!

• How to cooperate with “comers”? A piece of advice for a client :)
• A few words about choosing developers.
• Pricing methods & Project models.
• Active phase of software development.