Jurisdiction

The market of IT services is globalized. It is common (and cost-effective) to use the services of foreign companies, outsourcing to locations such as the Ukraine or Poland.

In a recent survey by Deloitte, 72% of the surveyed companies were outsourcing their IT work, with 31% looking to scale up outsourcing in the future. When asked about some the reasons behind the outsourcing decision, 59% cited cutting costs and 57% wanted to focus more on the core of their business.

Using cheap and skilled workforce from abroad is definitely a good idea, but you should always mind the implications. The cornerstone of your contract with a foreign supplier is the jurisdiction to which it is subjected.

There are two matters that should be considered here:

                     
• Competent court
                   

The competent court is the court which will hear any claim that is brought under the contract.

                     
• Governing law
                   

The governing law determines which national law will be applied by the court.

Surprisingly, the two do not have to match. Naturally, you want to use your country’s law and court, but to ensure it you and your supplier will have to expressly agree upon it in the contract.

Enforcing your domestic law and court will not always be possible, however. Here are some quick tips on how to proceed when negotiations are tough and no compromise on this matter can be found:

                     
• Try to use law foreign to both parties.
                   

This will make it similarly inconvenient for each side to sue the other. A common choice here is British law, which is used in many international contracts.

                     
• Insist on your local court, but agree on applying your contractor’s national law.
                   

This is a fair compromise, still it can make things messy in case of lawsuit.

                     
• Suggest that the contractor hire a law firm familiar with your national law to audit the contract.
                   

In addition, offer to compensate the cost.

Staff availability

In the world of software development services there are generally 3 types of contracts:

                     
1. Fixed-price contracts—they precisely specify project’s scope.
                     
2. Time-and-materials contracts—they do not fix price nor scope.
                     
3. Agile contracts—they usually fix the price to some extent without fixing the scope.
                   

The most common type of agreement among well-established software houses is the time-and-materials contract. This means you will be invoiced (usually every month) for the hours that your hired team spent working on your project.

When signing this type of agreement you usually focus on:

                     
• team size and composition,
                     
• transparency and control over tasks done,
                     
• the notice period on contract termination.
                   

What can be less intuitive is to make sure the team that you have hired will continue to be available for you. Due to high demand for their services, software houses face the temptation to redistribute some portion of the time of your team members to accommodate new clients or to provide support for a project in jeopardy.

This means that you not only want to specify the team size in the contract, but also put some boundaries on the minimal availability of each member.

Staff rotation

Another common case among software houses is to rotate the staff frequently between projects. This is done to utilize best people in first phase of cooperation and then move them forward to the next engagement.

Such practices carry certain disadvantages. Even if the person leaving your team will be substituted with someone of corresponding technical proficiency, this can still cost you extra time (and money) since most new team members will need some time to get acquainted with the code base, especially if you don’t maintain a robust documentation.

However, you should keep in mind that moderate rotation within the team is normal and has a positive impact on the performance.

This is due to the “project-oriented nature” of professionals such as software developers—they get bored very fast and their productivity tends to drop after few months of working on single project.

Replacing part of the team and bringing in fresh blood into the team can energize everyone involved. Remember to regulate the procedure of changing team members to avoid rapid and frequent staff rotations.

Rights of use

When you hire a team to develop bespoke software, you expect to have exclusive rights to use everything the team creates. You also definitely want to have the right for yourself or another contractor to modify the software in case you decide to change the supplier.

The tricky part, though, is the way software development is conducted: in most cases developers use libraries and components that are meant to be reusable. These libraries and components can be a property of software house or come under open source license.

Many software houses have their own set of libraries which they have developed beforehand and would like to utilize when working on your project. This brings great value to you, since it saves your team time, therefore saving you money. Reusable libraries in most cases are also less prone to errors and bugs. If you’d like to use them though, don’t expect to get exclusive rights to them. The software house will prepare a list of libraries and will offer you a non-exclusive license to use them.

This is perfectly fine, as long as you remember about the basics like making the license transferable or unlimited by country and time. It’s also extremely important to have the right to modify not only the code to which you have full rights, but also the libraries under the license.

Be careful with open source and “copyleft”

It’s a common practice to leverage open source tools, components and libraries when developing software. The abundance and versatility of open source solutions brings enormous value and in today’s reality it’s completely impractical to refrain from taking advantage of it. Still, the abundance of open source comes with an abundance of licenses, which should always be taken into account.

There are some licenses unsuitable for commercial use and having them incorporated into your software can generate legal issues and costs. Even more dangerous are copyleft licenses, which have a “viral effect.” Any work derived from copyleft work must preserve the copyleft permissions when distributed, effectively turning your proprietary software into open source available to everyone at no charge.

To stay safe, you should make your contract forbid the use of open source software with the copyleft license. It’s also a good practice for the development team to use open source in a way that makes it easy to completely separate it from the rest of code base. This way of using open source should be enforced by the contract.

Object code and source code

Under a time-and-materials agreement you can expect a demo of working software every couple of weeks. When you pay the fee for another month of development, the software which was presented should be transferred to you.

Depending on the technology used in the project, the software can sometimes have the form of object code—an application which user can run. You, as a user, would be interested in this form, though you should always remember to insist on also getting the source code. The difference is that you can’t easily analyze or modify object code, while you can do it with source code.

There are couple of different ways of transferring source code. Many of them works with online repositories like GitHub. The contractor can use their account to upload source code and then share it with you.

This is convenient, since you don’t have to bother with administering and paying for the repository, you also have instant access to code developed by your team on daily basis. At the same time, relying on the contractor’s account means that he can always cut you off from his repositories. For this reason, it’s always best to be the owner of the repository or to create regular backups of the developed code.

Documentation

No matter how small the software, it’s always good to have it documented.

There are 3 types of documentation that can be generated for the project: technical documentation, user documentation, and project documentation.

1. Technical documentation

Technical documentation is the most valuable. Its goal is to make it easier for programmers to understand how the code works. It’s useful when new member is joining the team or when you decide to change the contractor.

Technical documentation also has positive impact on the team’s work even if the team itself stays unchanged. Writing code is a complex operation and it’s not uncommon for a programmer to struggle with understanding his own code after 1-2 months. Having human-readable instruction will help to debug or further develop the code in the future.

Technical documentation comes in two forms:

                     
1. inline comments inside the source code,
                     
2. a separate knowledge base (stored in PDF files, a wiki, Confluence, and others).
                     

You should demand both.

2. User documentation

User documentation is the manual designed for the end user to help him learn how to use the software. It often includes screenshots and examples of use.

If the software you are buying will be distributed among a large group of people, it’s always important to have user documentation—it can save you money on live trainings and support later on. You should also have in mind that today’s software tends to be complicated and can’t be efficiently utilized without substantial preparation.

3. Project documentation

Project documentation refers to materials produced in order to manage the work during project. Having access to project documentation is essential for time-and-materials contracts because it provides transparency. You are paying for the time used and you should demand full transparency on how it is used.

As the contractor does not guarantee the outcome of work, you are taking the full risk of project failure. It’s you who should monitor the situation and make decisions.

Project documentation can provide data to help you. It comes in various forms, such as:

                     
• project cards,
                     
• JIRA tickets,
                     
• time logs,
                     
• burndown charts,
                     
• velocity statistics.
                     

When signing a contract, you should always make sure that the team you hire will be obligated to produce and continuously maintain the documentation of different types. Technical and user documentation should be transferred to you as often as the source code, and project documentation should be accessible for you at every time.

If you will be using online tools for documentation like JIRA or Confluence, make sure that you own the account specified in the contract so its content can’t be taken away by the contractor.

Final thoughts: the value of a well-prepared contract

I hope this list will help you navigate your way through the contract negotiations. A contract on its own can’t ensure smooth and effective cooperation with software house, but it will be a great protection in case hard times come. Knowing the tricks behind the IT contracts will also help you judge the honesty of your future partner right at the beginning of cooperation.

Spending extra time to set up the cooperation well is definitely worth it—the gains of software development outsourcing can be enormous. Not only can it lower the overall cost and save you the burden of adding extra department to your organization, but it also tends to produce better quality of work and gives you more flexibility if business conditions change during the process.

The list above consists of some of the most interesting cases, but it does not exhaust all of the elements you should look at. Other examples include contractual penalties or the distinction between culpable and non-culpable delays, among others. Luckily, these areas will probably be known to your legal advisor.

What is your experience in contract negotiations? Were there any misleading or risky paragraphs you wish you had never agreed on?

Putting together an effective contract is only the first step toward an effective software development outsourcing or nearshoring cooperation. Make sure to check out our free guides to outsourcing or nearshoring and save yourself from frustrations in either process.

If you have any questions or need advice, you can reach me at marcin.zabawa@stxnext.pl or via LinkedIn. I’d be happy to help.