Procurement perils

Fiona Robertson from the Rights Lawyers tries to give you some words of comfort in relation to setting out contracts for IT procurement.

Tags: United Arab Emirates
  • E-Mail
Procurement perils ROBERTSON: Specs within your contract must state what the software is supposed to do.
By  Fiona Robertson Published  April 26, 2010 Arabian Computer News Logo

There comes a time in every business’ growth when it must consider upgrading some of its IT systems. It is quite easy to find out when this is happening, as the management team can usually be found huddling in a corner and shaking with fear.

Because with IT procurement comes IT procurement contracts and, strange lawyers aside, nobody likes to deal with their intricacies and jargon.

There is no doubt however that the contract that you use to obtain a new IT solution is the only safeguard you are going to have in ensuring that the solution that you are spending months working on and paying for is actually going to deliver all of the things that you need. To try and make management less intimidated by the thought of dealing with IT procurement, here is a short checklist of the things you need to consider beforehand to make sure that the final contract works for all parties.


This is not rocket science. If something is not noted in the contract as having to be delivered, it won’t be delivered. Think of it as a pizza. If you want mushrooms, you need to ask the pizza shop to put them on. If you don’t ask for the mushrooms, you aren’t going to get them. Similarly, if you haven’t listed mushrooms and mushrooms are delivered, you have good reason to complain. Be accurate in specifications, insert details of required interactivity, describe the size and scope of desired reports and processes. All of this is vital.

The Rights

One thing for the parties to consider in any IT procurement is whether the party who is commissioning the IT solution is going to own it or whether they are merely getting a licence. This is so often overlooked by commercial managers until the very last minute.

Suddenly they realise that, in not discussing this from the start, they are going to have to tell their line manager that they don’t own the IT solutions, competitors are able to acquire the same IT solution, and (ahem), the enormous fee being paid doesn’t give any exclusivity whatsoever. You may not be able to pass the IT solution on to your affiliates, subsidiaries or branch companies. When caught in the negotiations for new software it’s easy to end up signing a simple end-user licence agreement instead of one that properly acknowledges your rights as the owner of the IT solution. So bring this up at the start.


The period in which the IT solution is tested with the hardware and any other software with which it must interface is a crucial time for both the developer and you. Within this, you have to identify clear objectives and timelines. There must be realistic penalties for failure to have the IT solution available and bug free by the end of the testing period.

It is strongly suggested that all software contracts contain a final payment that can be withheld if the developer fails to deliver on time and without defect. Again I cannot stress enough that the specifications that you have within your contract must clearly state what the software is supposed to do – how does it run, what does it create, how does it report – so that when the testing is being undertaken, you have a real guide to use to ascertain the success of the IT solution.

Add a Comment

Your display name This field is mandatory

Your e-mail address This field is mandatory (Your e-mail address won't be published)

Security code