It’s All In The Outsourcing Contract

When you outsource software development to a software development company, the single most important issue is control. This is particularly true if the project is a large one involving multiple programming teams and more than one project phase. You, as the client have to have some methodologies built into the relationship so there are routine checkpoints that are not optional but absolutely the law of the land in regards to the binding relationship between yourself and the developer.

The only way to achieve the level of control you need is to establish it early in the relationship with the developer. This means that you stipulate as part of the RFP that the developer includes checkpoints and modes of communication within their proposal so they are committing to accountability and control from the moment the contract is signed until delivery and sign off.

This is particularly important in a relationship with an overseas developer. Even elements of a contract relationship that we might consider to be “assumed” must be spelled out in a cross cultural relationship. You cannot make any assumptions in such a contracted relationship because simple things like holidays off, intellectual property protection and frequency of communication that may be natural to you may seem totally odd to the contractor. Nonetheless, by spelling out your expectations, the contractor, even if in another culture, will learn to live up to your requirements in order to be successful.

While most software developers in western cultures have come to use some form of project management method based on the time honored Systems Development Life Cycle, you cannot make that assumption with software developers overseas. Even if the project management at the detail level will be outsourced with the project itself, you, the client must maintain a senior project leader status so you are in charge of the project schedules, the milestones, the migration through project phases and change management as well.

By authoring the project business objectives, the requirements definition, the scope document and the project schedule before you put out the RFP, you are starting with the assumption that any software development consulting firm or freelance individual will live up to those documents as part of the proposal. This is especially important in terms of enforcing routine status reporting and escalation procedures in the event of project delays. You not only do yourself a favor by building these assumptions into the contract with the software developer, you do them a favor as well because they have an understanding of the protocols in the event of development difficulties so there are no gray areas in how to interact with you, the project sponsor, and the agency to whom the contractor is ultimately accountable.

Some of the basic understandings of the actual development process should be included in the contract with the developer as a result of their input to the process as stipulated in the RFP. If the developer is starting from an established product, that will effect the development timeline considerably. So whether that is the case of the developer is working from what you give to them, the flowchart and technical specifications should be understood before the contract is signed as well. These specifications will also help the developer spell out costs for development because of the need for compilers, developing and testing platforms or other necessities that impact the proposal they submit.

It is better to help your developer submit a complete proposal rather than receive a response to the RFP that is low cost but insufficient to the task. By putting in extra effort up front before the contract is signed, you will be sure that everything both parties need for success are all in the contract going in. And that will mean a much higher likelihood of a successful collaboration for everyone.