Outsourcing Software Development

Any organization will at some period in its life require software to be specifically developed for it. Whether it is a simple accounting package, or a high end, customized ERP or CRM solution, you will be faced with an outsourcing option. How do you check up on the antecedents of a prospect, and how do you ensure that your interests are protected in the deal?

A lot of such decisions are made by the good old referral method; of asking someone who has already tread the same path, how their experience with the developer was. If you don’t know any, you could ask the prospective developer for a list of clients. Ask for clients, rather than specific people at client organizations. Another way to judge a prospect is by checking for repeat assignments to the same client.

Relevant knowledge and experience

You need to find out whether the developer has experience in the kind of project you have, in the environment you want it deployed. For example, a particular developer may be great at creating Windows desktop applications, but may not have any experience, say, in Web applications or on other platforms like Linux or Solaris. This is particularly important if you are planning to give the work to smaller firms.

Research

It would do you a lot of good to do a little homework yourself. For example, are ready-made solutions or parts thereof already available at a nominal cost? Get a written project brief ready, including a process-flow chart. It will make the development cycle much smoother. If you do not get around to doing this, then ensure that the chosen firm gives you a good process document before they start writing code.

Pre-project briefings

When discussing the project with a vendor, make sure that they have at least one technical member on the negotiating team. Many-a-time, marketing people make promises on behalf of the technical teams that may be unreasonable or misleading. 



If you have someone in your organization, with experience in the kind of work you wish to outsource, it would be worthwhile having that person along for the meetings as well. However, having a network administrator for a project that involves hard-core programming in C++ would not be of much use.

Do not let any vendor bully you into accepting terms unless they are reasonable to you. For example, in a given situation, it may be faster and less expensive to ask the vendor to use readymade third-party components in the development, rather than to create one themselves, which not only adds to the overall cost but also to the time. However, if the vendor insists that they have already developed the component or have something similar, ask for a demo and see whether they have the required functionality. This is where the research you should have done regarding other similar products would be of help.

System analysis and design documents

Depending upon the vendor, you may or may not be charged for this. Whatever be the case, go through this document with a fine toothcomb. Make sure you note down any discrepancies or missing items and intimate the vendor of these. These can happen by accident or misunderstanding or could be left out as a loophole for the vendor. So make sure that the document covers everything you need and agreed upon in the pre-project briefs.

Schedules and contracts

Decide on a mutually agreeable schedule for both you and the vendor. Also make sure that you and your team stick to your schedules, if any, in providing the vendor with anything they need. For example, you may want a design company to do the design for pages in Web related work. However, if you give the designs later than was agreed upon, the whole schedule can be disturbed.

The contract should contain the scope of work in detail, along with schedules, deliverables and payment terms, and testing procedures. Have these as annexures to the main contract body.

A lot of other relevant matters need to be addressed in the contract also like the question of who owns the code. If the solution being delivered is in the form of binaries, the developer usually keeps the code. If you do want to obtain the code also for later review or further internal or other vendor upgrades, you will need to inform the developer, incorporate it in the contract, and be prepared for an increase in the cost.

Progress tracking

If its a long term project, don’t just leave the vendor to do what he wishes for a long time. Make sure you track the progress of your project with him at reasonable intervals. Of course, this doesn’t mean that you call him up every hour or every day. 



Testing procedures and teams for QA should be decided in advance before a deliverable milestone arrives. Feedback should be provided within the testing time decided upon, and should be clear and concise along with steps required to reproduce any problem you come across. Mentioning things like ‘I can’t add an employee’ makes little sense. Detailing the procedure that you undertook to add an employee along with the exact error you got would be much more helpful for tracking down and rectifying the error.

One thing to keep in mind is the possibility of radical technology shifts midway during the project. You can choose to continue with the same technology or move to another one. But you will require to bear additional costs in such a scenario. Remember that the vendor would remain comfortable to continue in the same technology that has been decided on as he would have already spent a considerable amount of time and effort for this project.

Handover and training

Once the project has been checked and qualified by your QA team, you need to accept the vendor’s project handover to you. If your contract requires training, this starts now. If you are in overall charge of the project, do attend at least one set of the trainings being conducted.

Finally, making payments on promised schedules motivates them to work harder and better

for you.

Warranty

Another thing to keep in mind is about the duration of the warranty and maintenance contract with the vendor? It should be of enough duration to not only check out the functionality of the software, but also let it run long enough for any non-test case scenarios to emerge and see how the solution responds to that. However, it cannot be an infinite length term and needs to be clearly addressed right at the beginning.

Also, have an understanding with the vendor for upgrades/patches delivery, even after the maintenance period is over. This can be on a per-case basis or on an Annual Maintenance Contract method. Both methods have their pros and cons in terms of cost and delivery schedules. Choose whichever is best suited for you.

Vinod Unny is a technology consultant at iSquare Technologies