Technology
I want to hire a software developer to deliver a new financial package. Should I accept his standard contract terms?
This may not be a good idea.
A user's main requirements in the procurement of IT systems and products ("Product") are likely to be that: the Product should do what the user wants it to do; that it should be delivered and ready for use in accordance with the user's requirements as to timescale; and, that the user should not have to pay over the odds for acquiring the Product.
A supplier, on the other hand, will wish, as far as possible, to maximise its revenue from the project and minimise contractual commitments to meet the user's requirements, in order to reduce its exposure to claims if it cannot meet those requirements.
The contract will probably need amending to reflect a compromise between these goals.
What, then, should the contract contain?
User's Requirements:
For development work and the supply of systems these requirements need to be identified and set out in writing. Traditionally, this has been achieved through the Specification document. If the user does not have suitably qualified internal resources, it will be unlikely to prepare the Specification itself, but will engage a specialist to do so.
Frequently, Specifications are written by the supplier - on the basis of information from the user as to the intended (and other possible) uses for the Product - as part of the development contract, or in a separate contract solely for production and approval of the Specification. However, in order to ensure that the supplier has embodied all the user's requirements for the Product, the Specification will need to be carefully reviewed by the user, or by a consultant appointed by the user.
As part of its review, the user should remember that the supplier will not have the user's, but the supplier's own, best interests in mind when preparing the Specification, the less concrete and ascertainable the requirements, the greater the potential for the supplier to avoid liability for those requirements and the greater the scope for misunderstanding by either party of the other's perspective. The user will therefore need to ensure that the Specification provides an exhaustive description of the required performance and functionality of the Product, set out in clear, objective and measurable terms. Generally, if a requirement is not contained in the Specification, it is unlikely that the supplier can be compelled to satisfied it.
Timetables:
IT projects can easily overrun, and frequently do so. It is important that users (and suppliers) consider very carefully their time constraints and ensure that the contract can accommodate them. If the supplier receives details of the user's requirements as to timing at the outset, and these are incorporated into the contract as concrete obligations, then not only will the user have a contractual remedy if milestones are not met, but the supplier will be forced to consider carefully the user's requirements, and to ensure that it has the resources to meet them, prior to entering into the contract.
For more complex projects it may be advisable to split the development or supply into phases, each phase being allocated a deadline, or "milestone", which must be met. If this process is adopted, problems with timing can be identified at an early stage and remedial action taken, without threatening important deadlines for final acceptance or implementation of the project.
User's Obligations:
Where a user is to have active involvement in implementing a project, the extent of its obligations should be agreed upon and included in the contract. This process assists both the supplier and user, as the user is made aware of the supplier's expectation of it, and it helps clarify the extent under the contract of each party's responsibilities, and liabilities, for the success of the project.
Ownership of the Product:
Products comprise valuable intellectual property (such as software, which is protected by copyright). The question of who will own the Product can be contentious, and negotiations heated. The likely starting point for negotiations is that each party will seek to acquire the intellectual property rights in the Product.
In development projects, in particular, the supplier is likely to be working closely with the user. Ideas which are implemented through the software may originate with the user as much as the supplier. Further, the Product may be of particular strategic importance to the user (for example, giving it a leading edge over its competitors). For these reasons amongst others, the user may wish to own the Product developed, so as to prevent re-use of it by the supplier.
Suppliers, however, are normally very reluctant to provide their customers with assignments of intellectual property rights in the developed Products. There are strong business reasons for suppliers expecting to hold on to those rights, as the Product may well have a valuable potential market which the supplier would wish to exploit, or the supplier may wish to adapt the Product to suit other projects or markets.
Settlement of this issue during negotiations will be affected by a number of factors, such as the relative bargaining position of each party, or the price the customer is prepared to pay in order to acquire those rights. There are alternative means by which the wish of the supplier to re-use software and know-how can be met, whilst protecting the user's particular needs. A satisfactory compromise might be where the user is granted a wide licence to use (and perhaps modify and enhance) the Product, but the supplier holds on to the intellectual property rights, so that it can re-use and exploit the Product, perhaps subject to reasonable restrictions on licensing of the same or similar products by the supplier to major competitors of the user.
I want to hire a management consultant to streamline my IT processes. Should I accept his standard contract terms?
This may not be a good idea.
The requirements of a user of IT services are likely to be that services should be provided in a prompt and efficient manner, by well-qualified staff and for a reasonable cost.
On the other hand the supplier will try and limit the extent of services comprised in any fixed charge, whilst endeavouring to ensure that response times are not unduly onerous to meet, and that provision is made in the contract for additional charges to be levied by the contractor where possible.
The contract will probably need amending to reflect a compromise between these goals.
What, then, should the contract contain?
User's Requirements:
As with the supply of IT products, the user will need to reduce to writing in clear, objective and measurable terms what its requirements for the services are.
For example:
In support contracts, the user will normally seek to include in the contract appropriate levels of prioritised support and times for responding to problems; for critical faults in software very short response times of hours rather than days may be required, whereas for more minor faults, response times may not be so important. Furthermore, it is important for the user that the nature of the services is clearly defined, including the hours during which any help-desk is staffed, and who will run it, and when site visits must be made by the supplier (normally for more serious faults or when telephone diagnosis fails to remedy a fault);
Or:
In consultancy or programming services, the user will need to describe clearly and specifically the nature of the services to be provided, such as the hours to be devoted to the services and the required deliverables. The contract will also need to specify who will own any such deliverables supplied as part of the services (see above on the issues of ownership).
User's Obligations:
The precise role and the extent of the user's responsibilities under the contract to enable the services delivery to be facilitated, perhaps by the prompt provision of information to the supplier on request, should also be considered and incorporated into the service contract.
I have a great idea for a new business/software/website; how much can I tell the venture capitalists about it?
You would be best advised to ensure any third party signs a non-disclosure agreement (or 'NDA') before you give them any details. Otherwise you may have little or no redress against them if they copy your idea.
