IT Contracts

From Granizada

Jump to: navigation, search

There are some basic things I look for whether I am on the purchasing or supplying side of an IT contract.

One-off IT Proposals

For contracts betweeen a large company and a contractor who doesn't have a relationship already with the large company (or, sometimes, even if they do.)

Elements of this can be extracted for simpler engagements. Some of the terminology is slightly tilted towards Asia-Pac and US usage, but I've seen it in Europe as well.

IT purchasers issue a Request for Quotation (RFQ). There might not be a formal document called an RFQ (such as there always is for public tenders) and sometimes there is just a verbal request, but a contractor always treat a request from someone at a large company with budget signoff capability as an RFQ. The contractor should get the RFQ in writing if at all possible, particularly with traditional companies, however fast-moving companies sometimes don't bother and can respond to submissions in a matter of days or hours. More usually submissions take weeks or even months to filter through the various layers in a large company, which is why an IT contractor (and the requesting organisation) need to calculate the cost of responding to an RFQ.

The requesting organisation sometimes specifies the format of a response, occasionally in great detail (especially government.) In this case, the contractor needs to evaluate whether the format will prevent a good case being presented. A restrictive RFQ response form is usally a sign of an organisation that is very painful to deal with. It is very rare that the response forms embody technical competence.

The responses to an RFQ are of course Quotations, but are usually called Proposals. Proposals contain a Statement of Work within them or attached to them. The Statement of Work (SOW) is the description of what needs to be done and often why the work needs to be done. Repeating the words of the RFQ is really bad form and should lead to the proposal being disreagarded. Besides, an RFQ is often innaccurate and in the case of a verbal request you need to define the scope of the engagement from scratch. The SOW is your opportunity to show very concisely that you understand the problem. The goal is to make the reader interested enough to want to evaluate how much you are going to charge for your well-crafted solution. It also is your chance to set boundaries on the work to protect both yourself and the customer. You will sometimes be addressing either more or less than the RFQ, but if you state your reasons that should not be a problem except where the RFQ mandates exact compliance.

The List of Deliverables and Project Schedule with Milestones sections are always required. Even if the Deliverables are somewhat abstract, they are still the item being charged for.

The Proposal also has a Price Section, which has three schedules (call 'em tables), being a Price Schedule, Rate Schedule, and Hours Breakdown Schedule.

There should always be a Terms and Conditions section, which includes any warranties.

The word Estimate should be used in the preceding headings if this is not a hard committment. If it is a hard committment (eg fixed-price, or fixed-deadline) then that should be made clear in the first paragraph of the whole document because that's what the accountants will notice.

Head Agreement and Work Requests

A larger company with a regular IT contractor has a Head Agreement in place, which specifies the general terms of ongoing work and the format for each Work Request. Either party can raise a Work Request, which is a streamlined form of Proposal. The Head Agreement is either time-limited, or certain sections have time limits or provision for updates in them, most obviously Costs. The Head Agreement also specifies legal compliance information.

You do not necessarily need to have a large business volume to establish a Head Agreement, just one transaction is sufficient if both parties think there is the possibility of ongoing work.

The Work Request consists of brief versions of:

  • Statement of Work
  • List of Deliverables
  • Price Section (may be folded into the List of Deliverables)
  • Hours Breakdown Schedule (for hourly-billed work)

Work Requests are a good match for issue tracking systems in terms of IT contracting workflow. A Work Request should have a unique number distinct from issue tracking numbers because it is about financal authority not technical authority, but the two will often be related.

Personal tools
Navigation