Transferring project to a new team: recommendations for customers

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:

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:

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?

  1. Formulate your demands for the project:– Business Logic- Design- Functionality.
  2. Give access to a new provider:– To the code- Any databases- Records and other source data.
  3. To order your project testing by new team to identify / compare actual and estimated degree of project completeness.
  4. 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.

Our company receives regular requests for completion of partly-made websites. And in such cases the clients are genuinely convinced that their 90% ready sites just need to be finished with tiny efforts. But in fact the things appear different…

In such cases there is the only question with two items:

Qualium Systems’ experience of cooperation with such clients shows that the first item can be answered in two ways excluding force majeure clauses of either software provider or its customer.

Hard divorce

Oddly enough, but in matters of computer programs the human factor often plays a vital role. It means the customer simply fell out with software provider and now he’s simply looking for a new dev team. Such “love story” seems alarming as the client would unlikely explain true causes of the conflict.

Well, we may assume that the divorce happened due to initial incoherence of the work scope or as a result of client’s financial default. But anyway, the new provider should carefully assess all risks before taking a project with a dubious history.

Hidden dilettantism

Another possible answer might be that the dev team is incapable to finish the job, and even clearly admits it. So, we gradually move to another side of the issue to be clarified as well: who and how has evaluated the actual project readiness (why 90 %?) and how much effort will it really take to be fully completed.

Most often the reasons of project incompletion lie in primary architectural and structural failures making a half-done software product go into pieces: after fixing one thing the other ones stop working or load test fails due to incorrect database structure, etc. So, before you agree to finish an off-site project, we strongly advice to estimate its true readiness for further modification and tech support.

Evaluation – conclusion – decision

Full functionality testing and examination of the project’s internal structure allows indicating all parts needed to be improved. Also the meticulous review of project code gives ground for quality assessment of ready-made parts and the whole website architecture. SRS (software requirements specification), use cases or test cases could either help significantly, but our experience shows that such projects have been usually implementing without proper documentation.

That’s why it’s best to start with internal examination, since the analysis of the undone website can be finished just after its code review. Once the results are negative, there are more reasons to discuss rather the website’s full rework than simple completion.

But if the client still firmly insists on using his “legacy code”, the project can be completed under time & material model. In this case the software provider carries out the client’s instructions on required corrections without any responsibility for bad functions being not fully retested beforehand.

Don’t rush to dead end

Many customers however keep following the misconception that finishing uncompleted project is quick and easy task; or at least it’s faster than doing it from scratch. Right, a project will be done like piece of cake, if it has originally competent architecture, well-designed modules and good-structured code.

But once the current status of the project needs much to be improved, its further development will definitely lead to a dead end regardless of many money-wasting “patches”. Perhaps it’s wiser to admit the failure and spend more time for careful selection of a new provider. Such an approach surely gives your failed web project a chance for survival and long productive life.

Fasten the belts

It’s ok if a technically competent client with managerial experience has a strong will to be the leader of his/her own project. In this case, the project team might operate normally, i.e. without decreasing in performance and quality. Even the distance and time difference as well as national peculiarities wouldn’t affect the final high-grade product performed after customer’s wishes.

But what happens if the control stick would appear in hands of a pilot’ knowing how to fly a plane after reading a book? Or what’s the fate of a jet being steered by a person who had repeatedly seen others doing that and therefore has a strong confidence in his/her capabilities? The answer is clear: an aircraft (i.e. the software project) would reliably crash down, and its passengers (both client and software company) are appeared to become its victims.

Project manager: a short description

In fact, project management is a complex multistage system that can be simply collapsed as a result of amateur’s interference. The project manager, once we use building terminology, doesn’t just coordinate the team of builders, but also combines the roles of architect and building engineer.

Firstly, the manager has to describe and scrupulously document HOW and WHAT should be done. Then the manager must choose a proper team of specialists with specific skills and experience. And after that, the same manager is obliged to compose a development plan in order to distribute tasks among all members of the project team.

It’s obvious that the project manager takes a great responsibility by supervising every project phase and monitoring the effectiveness of every team member. Also one shouldn’t forget about communications with a customer willing to include additional amendments while the project is running. It’s quite understandable that the client is hardly able to think out everything before the project starts, although the Agile methodology as a leading one in our company implies flexibility towards the initial project scope. But any client’s suggestion announced on the run must be analyzed, agreed and properly included into the entire process of product creation. And who’s responsible for that? That’s right, the useless project manager.

Responsibility found. Caretaker is needed

First of all, a client who wants to take responsibility for project management, is supposed to understand that mistakes done by programmers are indeed mistakes of the manager being failed to provide an appropriate explanation, check or estimate time, resources and so on. Basically, such kind of a client-manager tends to blame everyone but him/her; and the more mistakes are made, the greater level of his/her dissatisfaction with the project team. And as a result, there’s an eternal project with variable number of soldiers and weapons, but constant irritation of its Commander-in-Chief.

What about the tester? There’s a common image of this person as an ordinary user, randomly clicking on program’s menus. But contrary to the client, testing engineer has a professional technical background that allows him/her to conduct a full test procedure after specific pre-test plan according to a certain adopted methodology and with usage of proven programming tools. The tester is fully responsible for a final product working fine within any scenario of user behavior. It means that a professional tester must provide a guarantee of the product quality. Is any client-tester without certain skills and expertise ready to give such a guarantee?

Money-losing saving

It’s worth mentioning that Qualium Systems strives to safe its customers from making painful mistakes, however leaving them the right for the choice of collaboration business model. Our long-standing experience reveals many cases, when such an alleged saving yield significant additional costs due to incorrect risks calculation, thoughtless decisions and/or inappropriate use of resources. Therefore, while rejecting paid management and testing, the client with a great desire to manage his/her project personally should set priorities between dubious optimization of the project budget and creation of a professional high-grade product.