Here at Elinext, we often find ourselves in situations when we are asked to complete a project which was developed by another company. When analysing such proposals, a new team has to understand why such types of requests are considered being too risky. On the other hand, we are not living in a perfect IT world, and teams need to address such projects without prejudice. Besides, such requests could become an excellent opportunity to start a prospective relationship with a new client (if those requests are managed wisely for sure). In this short article, I will give a few tips on how not to fall into the trap of unpleasant surprises.
First of all, let’s recap the most popular engagement models for such projects:
– Fixed cost. Briefly speaking, we have to give a fixed time, fixed cost commitment for a fixed scope of work. Usually, clients consider this model as the safest model for them, so they insist on using specifically this model for completing an unfinished project. It’s always the case if they were not lucky with the previous team using another model. The downside of this model for the development team is this: if they underestimate some features, they will either need to convince the client to extend the budget and time frame or will have to implement those features taking costs to themselves.
– Time and materials. In short, the client needs to pay for actual efforts (in most cases, it’s time spent on development) performed by the team. There are different variations of this model (i.e. time and materials model with guaranteed maximum price), but often the client is charged according to time reports.
In order to bring such projects to a successful ending, teams should keep in mind the following points:
– As for any other development, one should not give commitment until one identifies discoverable risks, assess their significance and plan mitigation actions.
– It makes sense to start with the investigation phase. Depending on the size of the project, put the revision of the source code on schedule and ask for any available documentation.
– There is a good saying – “don’t change horses in midstream”. Carefully ask your client about the project origins. Apart from technical details, ask about communication with the previous team. After all, you should have a perfect understanding of what eventually went wrong. Changing the team during the phase of active development is a big stress for the product. You should be aware of the reasons why the team was changed.
– When estimating such requests, it’s good to find out beforehand if the previous team is available for questioning and if they can be of assistance during the very first steps of development. Most likely you will have questions on the chosen development approach or why they implemented a feature or two in this particular way. Besides, it always makes sense to hear the other side, so you can ask the previous team about problems they met during the development.
– If you follow the fixed cost model, try to get acquainted with both functional and non-functional requirements. It would be a wise move to outline them in the contract along with limitations. Make sure it’s clearly visible what has been already implemented in the system and what is required to be finished or fixed. And leave no place for interpretations: all the requirements should be written unambiguously.
– If you are asked to deal with a short list of fixes following a fixed cost model (if you are interested in that, of course), it makes sense to take a snapshot of the current state of the system. If the client finds some new bugs it can be clearly visible that it’s not the consequence of your changes in the code. There are several suggestions for that: all issues that are subject to a fix should be clearly described, all workable functionality should be shown during a web conference call and recorded. After all, this might be helpful to understand how the system works. In order to be sure that some hidden bugs will not pop-up as the result of the regression caused by your fixes, deploy one more instance of the system before you start making any changes. It will help you to compare the version with your fixes and the initial one.
– If you have time, make certain that there are no core flaws in the system architecture and test the system under the heavy load (using JMeter, for instance). Try to avoid the temptation to rewrite everything. However, if there is a real issue in the fundamental parts of the system, an inappropriate architecture or too many hotfixes due to poor initial decisions, you have no other alternative than to rewrite the whole project. However, in this case, some previous components can still be used. It’s not always the case when you have to throw all previous work into the trash bin.
– One way or another, the time and materials model shouldn’t be regarded as a magic bullet. Some teams tend to think that if the client agreed following these contract obligations they are safe. Later on they realize that some issues are not even fixable, and the client starts a lot of disputes about the results and performance. Then development team sadly realizes that they should have done the investigation phase first before signing the contract.
Taking over someone’s else project may carry risks, but it’s not necessary to decline such requests. We have many successful cases which started with the request to complete an existing project. An excellent way to proceed with such requests is to speak with a client clearly and transparently. Feel free to explain your concerns, while taking into account the tips described above. It’s preferable to implement such projects using time and materials or dedicated team models but anyway, the investigation phase is useful before the development. It also makes sense to explain to your client that the new team will need time to get up to speed with the project. They will not generate value right away.
For instance, the new team may suggest to refactor the code first and update some libraries and components. Also, the client should be actively involved in the process. It’s especially vital during the first phases of the development as the team needs an explanation behind business logic. Delegating a project to a new team may be very complicated for both parties, but proper communication, transparency, planning, risk awareness and common sense are the key factors to achieve mutual success.
P.S. Have you ever faced such projects in your life? Or maybe you still have questions on the topic? Let us know by contacting our specialists at [email protected]
