Here are 12 things to consider when evaluating technical contracts and negotiating with vendors.
1. Consistency and Neatness
It may sound like a no-brainer, but looking out for consistency and neatness is a good general rule of thumb. Messy contracts are more likely to have problems. If different clauses are making contradicting statements, there is a good chance the contract has been ‘copy and pasted’ from multiples sources, leading to contradictions and non-relevant clauses. The contract can be based on a template but it should be customised towards your project, with terms relevant to the current scope. It is better to create a new contract in the future if the scope significant changes instead of having lots of unnecessary clauses.
The wording of a contract can make a huge difference. Make sure there is no room for ambiguity in clauses. For example, is the vendor “obliged” or “expected” to deliver something, or are they “required”?
2. Avoid Fixed Price
Fixed price should generally be avoided as it creates a false sense of security and is not effective at managing expectations. Instead, use milestone payments or for bigger projects, monthly payments. For monthly payments, all actual hours could be billed at the end of the month or predicted costs at the start of the month followed by any corrections at the end of the month. (Read here for more on why fixed price is not useful in projects.)
3. Working with Overseas Vendors
If you are working with an overseas vendor then, depending on their location, you might want to agree on the project price (or hourly or daily fee) in a stable currency. Ideally, you would use your local currency but a neutral, relatively stable currency such as USD or EUR could also be considered.
It is usually preferred to base your contract on the legal jurisdiction of your own country. However, it may sometimes be easier to get the vendor to accept a neutral country that has a strong reputation for transparency and the rule of law. Avoid countries with a reputation for bribery and corruption.
If you have contracts in more than one language, have a clause stating the one you understand is the binding one.
4. Team Expectations
Discuss your expectations in terms of the vendor’s skill set. Your idea of a senior development might different from the vendor’s. Set expectations for coding to current standards - there are both generic standards and more detailed standards for your project’s programming languages, quality assurance, delivery and security - especially from a privacy perspective such as GDPR compliance.
Make sure to also discuss with the vendor if they need training or time to learn new skillsets for your project. It should be clear beforehand how much time is needed for this and who will cover the cost. Similarly, any travel expectations, costs and policies should be discussed and clear beforehand.
Clauses covering team member replacement are important to manage any risks of delays. After how many days absence due to sickness will a team member be replaced for example?
5. Contract Changes and Termination
How would you deal with changes to the contract, including price changes? Would it require written approval from both parties? For price changes, you could consider locking the price for contract duration or some other arbitrary term, and you can consider capping price raises. Not having such additional limits leaves a potential loophole open where the vendor could raise pricing to some arbitrary amount to get out of the contract.
Consider also the potential need for contract termination. If you wish to terminate a contract, how far in advance do you need to give notice. Think about how long you will need to find another vendor how it will affect your project timeline.
6. Code Ownership and Intellectual Property
If you are paying for the development of the code, then you should generally own the code upon payment. Pre-existing code and third-party code should be clearly defined together with limitations and any costs. These can be done outside of the contract with a reference to this in your copyright clause. You can keep a list of third-party codes and keep it updated as new information becomes available.
Make sure you have full access to your source code, ideally from the start of the project but at least after each payment for the work completed at that point.
With vendors, you are typically paying for a service to “develop your solution at an agreed rate”; you are not purchasing a license. So, it should not matter if and how you monetize your project. Be wary of clauses that state that special conditions apply if you sell or monetize the solution, or that prevent you from sharing source code with third parties.
Consider also the confidentiality period. It is best to start on the contract start date but also extend a specific number of years from the contract termination date as you may not know beforehand how long the contract will last.
7. Ensure quality work
Work in a clause to ensure that quality assurance is applied and that accountability is appropriately shared. You should receive reports for all automated and manual tests at regular, specified intervals. You want to see what was tested, on which devices or systems, how they tested it and what the outcome was. This will at least provide a basic overview of what was done and where the gaps may be.
8. Privacy Breaches
I ask vendors to be fully liable if there are privacy breaches as a result of direct actions by the vendor - such as failing to deliver code or cloud service configurations that meet minimum security standards, losing access credentials and not disabling them or leaving a server or database open to the public. This is potentially a lot of risk they are taking on so it is worth careful negotiation on the part of all parties so they understand what they are agreeing to. As part of this, you will need to clearly define what is considered “minimum security standards”.
9. How to Handle Bugs
Bugs can be a major discussion point in client-vendor relationships and frequently the cause of a breakdown of these relationships. Be transparent and clear about your expectations and ensure the inclusion of clauses to address this topic. Are bugs handled within the scope, or is debugging considered development work and billed accordingly? How is a bug defined and do they have different levels with different response and resolving times expected?
10. “Go-live” Accountability
Separate environments for development, staging and production are essential to managing custom software development. I recommend requiring the vendor to complete their internal QA in the development environment before they can move changes to staging. This is where your team will review before approving the changes to be pushed to the production environment.
Have clauses that define the accountabilities and repercussions for any issues in this process. For example, the vendor should be accountable for ensuring that staging matches the production environment. If issues make it into the production environment that are not present in the staging environment then the vendor is responsible for this. If you signed off on staging and later there are issues, then you are responsible for this. Similarly, if changes get pushed to production that you did not approve, this is also the responsibility of the vendor.
11. Shared Responsibility
The vendor needs to be responsible for their side of things, and be accountable for their team’s actions. You can limit liability to the total value of the project, which could be a large amount - and substantial risk to the vendor so they might ask for a fixed amount. If so, make sure the agreed amount is enough of a deterrent to ensure that the vendor monitors their team’s adherence to the agreed accountabilities and security policies. Keep in mind that privacy breaches could be very costly - 4% of revenue or up to 20 million Euros under the EU’s GDPR (For more information about GDPR click here).
You can try to prevent careless errors on the part of vendors by applying a penalty in the form of hours of work for each hour that a problem persists that the vendor is responsible for. (For example, X hours for each hour that the problem persists.) This instills some caution as to when the vendor decides to push changes, not at the end of the day for example, when there is a risk of them not being able to fix it until their staff is back the next day. And it places the cost of fixing careless issues onto the vendor.
If the vendor applies a penalty for late payments make sure to add an exception if you have submitted a dispute for that invoice. This dispute needs to be resolved before the late payment penalty can be applied.
Finally, it is good to remember that successful contracts are often the ones where both parties - the vendor and yourself - find positives in a fair and equitable deal that benefits both. This is far more likely to lay the foundation for a mutually beneficial, long term relationship with your vendor.
Personally, I find the legal implications of contracts somewhat pointless. Rarely do court battles work out for anyone but the lawyers. For me, a contract is more of a tool to manage expectations and to make sure both parties are on the same page before they embark on a major project together.