Preparing a good contract is no picnic, especially when it concerns a contract for an IT project that has a big impact on your organisation. Unfortunately, practice teaches us that often little attention is paid to preparing and negotiating a good contract, which may come back to haunt you later, as agreements turn out to be insufficiently transparent and lead to differences in interpretation. The contract is often seen as a necessary conclusion to a negotiation process (which has usually been going on for some time) in the course of which the parties are more than happy to have agreed on at least the price. However, it is often not until the contract is being prepared that the parties realise they do not really know what needs to be delivered and which requirements must be met. This document sets out five questions that help you assess if the core agreements are sufficiently reflected in the contract.
What, Who, How, When and What questions
The following practical questions help you to assess (IT) contracts. If you can answer the following questions, you have at least grasped the core of the obligations:
– What needs to be delivered?
– Who delivers What?
– How does Who deliver What?
– When does Who deliver What and How?
– What does When, Who, What and How cost?
What needs to be delivered?
This question relates to the scope of delivery. What falls within this scope and what does not? It is obvious that there must be sufficient clarity about this so as to prevent disappointment and discussions concerning extra work. Something else that needs to be sufficiently clear is the requirements (specifications) which the software or hardware needs to meet. Such a logical question, I can hear you think, but strangely enough it is a question that is not dealt with sufficiently in practice or cannot be answered properly at all. However, determining the specifications is very important, as not only will this define the scope of delivery, but at the same time it is the benchmark for the acceptance test to see if delivery was indeed made in accordance with the contract. Without a clear answer to this question, it is very difficult to assess if, from a legal point of view, a party has failed.
Who delivers What?
It has to be clear which party is responsible for what. Is the supplier the party who undertakes (virtually) everything and is the role of the buyer limited to providing the necessary assistance to the supplier (e.g. providing information about certain work processes, offering an onsite workstation, etc.), or is it a collaboration project, with both the buyer and the supplier having equal roles. The latter case will require strict arrangements about how those roles are allocated.
How does Who deliver What?
This is about how the software is implemented or installed. Is it necessary to start an implementation project? It is often necessary to make arrangements about a certain sequence. Such arrangements (along with question 2) will have to be properly documented in, for instance, an implementation plan, a plan of action or another document that forms part of the contract.
When does Who deliver What and How?
This question speaks for itself: there has to be a transparent time schedule with one or several clear delivery times. It will also have to be clear what has to be delivered at those times and by whom. A popular choice is to divide projects into different milestones.
What does When, Who, What and How cost?
This question understandably gets a lot of attention, but it would still be wise to check if all work to be carried out is indeed covered by the financial agreements. This wouldn’t be the first time to discover there are still uncertainties about implementation costs, for instance, because the focus was on negotiating that excellent licence fee. If it is agreed to deliver the software in parts (milestones), it is important for the buyer to link the payment dates to (acceptance of) those milestones. This will prevent the costs and deliveries from falling too far apart.
The above is a method to quickly identify the core of a contract. It is of course not a comprehensive method to realise a solid IT contract. You will also have to pay attention to removing or dividing specific project risks, and to warranties, service levels and liability for instance. However, if the core of the contract is clear, you are less likely to have to fall back on such provisions.
Ernst-Jan van de Pas
