When people invest in project development to implement their business ideas, they are expecting to work with a reliable team.
However, not all teams are able to meet project requirements, and sometimes a customer is forced to change development teams. A customer may find that the new team requires significant effort in order to achieve the desired goal as discussed here.
But as a rule, customers often don’t realize that the “abandoned” project doesn’t meet all the requirements it should.
Here are some of the most common problems with transferred projects:
- lack of technical documentation;
- lack of code comments;
- the absence of testing reports;
- a large number of bugs;
- a large amount of hard-code, which requires refactoring;
- problems with the architecture.
Most companies are reluctant to take up a project with someone’s else, because this is not a trivial task. In fact, it is often one of the most complicated tasks, but it is not impossible. If a customer still wants to hand off a project to another team without starting the development from scratch, he needs to finalize the work with the current provider properly, namely:
- get system’s documentation;
- perform testing (preferably, independent) to determine real amount of work done;
- ensure that the provider gave the customer a complete project – the latest version of the source code, database, source files, developed designs, and any and all other materials connected with the project.
If some data is missing (for example, the design was only in the form of PNG files), then this part of the work will have to be done again with the new team. If there is no source code or database (or incomplete source code and/or database), then the new team will have to start the project from the beginning.
What do you need to do as a customer to give the project a second chance?
- Formulate your demands for the project:– Business Logic- Design- Functionality.
- Give access to a new provider:– To the code- Any databases- Records and other source data.
- To order your project testing by new team to identify / compare actual and estimated degree of project completeness.
- Ask your new provider to give you details about the following aspects of your project:– The quality of the code / need refactoring- Overview of the application and database architecture- The possibility of working with the existing structure / code to add functionality- Approximate estimation of development time and development team.
Of course, even after following the above procedure, the customer is not insured against an unscrupulous provider.
In such a situation, you can protect yourself by getting a description as detailed as possible regarding each project point before starting work.
In addition, customers should realize that the attempt to limit the provider’s budget and the desire to make up for past losses when changing to the new developer will not lead to anything good – in the best case, the provider refuses to cooperate, at worst, the customer receives a product that will not meet initial expectations.
Based on the foregoing, the customer must be honest, not only with himself but also with the provider.
If your budget is limited – the provider can help with the definition of the scope of work that fit into this framework. Otherwise, there is big risk of yet another failed project.