Contract Review : How to assess the risks?

Where to start when reviewing a contract and assessing contractual risks?

The first step is always a detailed review of the entire contract, including attachments and references to other documents such as the terms and conditions or the project specification. You need to pay attention not only to what is included in the contract, but also to what is missing.

For example, beware of a situation where you order software development but do not have the terms of a service contract agreed upon in advance. These are often concluded later in software development, which can be risky as you as a customer become more and more dependent on the supplier. For this reason, we recommend that you agree on everything important at the beginning of the cooperation, while you are still in a stronger negotiating position.

Moreover, the risks in the contract are assessed differently by each party. If you are the client, you should focus on warranties, work schedule and liability for defects. In contrast, the supplier should watch for clearly defined payment terms and the possibility of multiple costs that often arise from unclear specifications.

Are you afraid that you cannot handle the negotiations on your own? Contact us ↗
and we will take care of the contract review.

Does the contract even match your project?   

When we talk about a software development contract, we have to look at the project from the beginning. There are three types of software development, where suppliers approach the entire software delivery, development and deployment differently. This then determines both the pricing and the overall approach to the project in terms of its progress and operation.

• Fixed-Price, Fixed-Time: the supplier is responsible for keeping to the budget. He must keep track of every change and assess its impact on terms and price.
• Time & Material with a non-binding estimate: Or the rate is fixed. But the supplier does not give a budget for the final output. The customer can end the work early and only pay for the work done.
• Team Lease: the customer has full control over the direction of the project. The contractor guarantees only the delivery of the capacity of the experts in the field.

Note that each of these types of development has completely different business parameters. Therefore, the contract must also look different. Remember this and next time you are dealing with the delivery of software work, think about whether its description in the contract corresponds to the nature of the project you have agreed.

Types of contractual risks

Risks can be divided into three main categories:

• Technical risks: these mainly concern the feasibility and concreteness of the work. A vague or broad specification may cause the contractor and the client to have different ideas of what the result should be.
• Business risks: these can manifest themselves, for example, in poorly defined payment terms or ill-conceived penalties for non-compliance with deadlines. It is not uncommon for changes to occur later in the project that can impact the price​ . Overlapping into the business side are output guarantees which can lead to claims for free repairs. However, a contract can also function without a warranty and with fairly broad limitations on liability.
• Licensing and legal risks: in software contracts, it is crucial to ensure that it is clearly defined who can use the software and how. And whether they are even entitled to grant a licence.

Would you like to find out more? We've prepared a webinar on risk assessment.

How to assess the severity of risks?

When we assess risks for clients, we categorise them into several levels according to severity. These can be high, medium and low.

High risks are those that could fundamentally affect the implementation of the contract and should therefore be addressed as a matter of priority. These include:

• Poor contract design: if the contract is based on incorrect assumptions, it puts the whole project at risk. For example, a situation where you order custom software development and expect the transfer of rights to be as broad as possible, but the supplier only provides you with a license.
• Impossibility to fulfil the contract: If you already know when you sign the contract that you cannot fulfil certain obligations, such as warranties on work that you have no control over (e.g. the software is running on-prem on the customer's servers and you have to guarantee availability without downtime).
• Lack of an exit strategy: if there is no clearly defined way to terminate the contract, it can lead to unsolvable problems in a dysfunctional collaboration.
• High contractual penalties.

Medium risks include issues that could affect your satisfaction with the contract, but are usually resolvable during negotiations. These risks often include:

• Unfavourable pricing arrangements: for example, the possibility of unilateral price increases or overly long guarantees of price stability. If these are not adjusted to your satisfaction, a compromise can usually be negotiated, such as capping changes or the possibility of early termination of the contract.
• Unreasonable deadlines: deadlines that are too short or long and likely to lead to problems​ . They may relate to scheduling, invoice due dates, or deadlines for providing assistance.

Low risks are points that do not have a major impact on the main objectives of the contract and can be considered as room for compromise.

Practical examples from software development

Example of risk for suppliers

Flawless implementation: a typical problem is the issue of completing the work. It is often contractually stipulated that the work must be delivered "free from defects and deficiencies", which is virtually unrealistic in the software world. There is always room for improvement and the customer is never completely satisfied. It is therefore preferable to agree to accept the work when predefined acceptance criteria are met​ . These should ideally be objective, leaving no room for creative interpretation by any interested party.

To increase the customer's convenience, a retainer can be offered at a percentage of the invoice, which the customer pays only after the defects have been corrected. However, it should not be the case that the customer will hold the entire reward until complete satisfaction with the output is achieved.

Example of risk for the customer

Project delays: one the most common problems in project development is that the supplier fails to meet the schedule and the project is delayed, resulting in financial losses or disruption to subsequent projects. The client can mitigate this risk by agreeing a fixed timeline. However, without delay penalties and clearly defined milestones, any schedule is toothless.

If the supplier will not agree to the penalties and you are concerned about delays, try to negotiate to defer as much of the price as possible until final acceptance. This will give the supplier an incentive to complete everything as soon as possible, otherwise they won't get paid.

Contract review is our daily bread and we have produced an e-book ↗ on risk assessment.

When is it enough to be cautious and when to negotiate?

Read contracts very carefully and take into account not only the legal side of things, but also the business and technical aspects. The important thing to remember is that not all risk is necessarily bad - some are a natural part of doing business and can be managed with well-set terms and conditions.

If you encounter an ambiguity or risk, it is important to assess it in terms of the potential impact and then decide whether it is a serious risk that requires direct action or a minor issue that can be managed internally. In either case, it is crucial to approach contracts cautiously, but also flexibly, so that negotiations lead to a win-win outcome.

Preparing, negotiating and reviewing contracts for our clients is a daily part of our work. If you do not want to wander between paragraphs on your own, the easiest way is to contact us. 

Pavel Čech ↗

Nejraději pomáhám těm, kdo potřebují skloubit právo s technologiemi. Ve světě IT a software se totiž cítím jako ryba ve vodě. Už od mala mě přitahovaly nové technologie a promítání science fiction do našeho světa. Až při studiu na vysoké škole jsem si však uvědomil, kolik etických a právních překážek je nutné překonat před jejich uvedením do reality.