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:
- why the team that began the website’s development hasn’t finished it, and
- in what degree the website’s readiness corresponds to reality.
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.