Information Technology: Contract Process

Parties to information technology arrangements that are less than straightforward can enjoy substantial benefits from a better understanding, and application, of a Contract Process.


By Contract Process I mean the steps that these parties can take to reach a written record of their relationship.


In this memorandum, I set out my thoughts about such a Contract Process. Initially, I set out some thoughts about:

  • the reason for a written contract
  • the content of a written contract
  • who should have responsibility for delivering the written contract, and
  • timing.


This memorandum should form the basis for further discussions about the Contract Process and, perhaps, our role in that Contract Process.


Reason for Written Contract


Before suggesting a Contract Process, I think it useful to explain why the end result of the Contract Process - a written contract - is desirable.


Ideally, a written contract is the reference point recording the commercial expectations of each party, the consequences if those expectations are not met (for whatever reason) and the process for managing the relationship. A written contract should provide certainty about the nature of the parties' relationship during the course of satisfying, and after the satisfaction of, the respective commercial expectations.


The expectations of each party are defined more precisely in a properly conducted negotiation of the contract. The negotiation process allows each party to better understand the expectations of the other and to identify respective abilities to satisfy those expectations.


A written contract provides greater certainty over an extended period than:

  • a shared understanding between individuals (who may cease to be involved with the contracting parties or may not have contemplated the effect of unforeseen actions)
  • a course of dealings, or
  • implied agreements



Often, the initial draft of the written contract is a battle of the forms . A Request for Proposals may contain the form of contract the purchaser claims to be able to sign and require proposals to identify all changes required to that form. Alternatively (or even despite the terms of the RFP!), a proposal may include the form of written contract.


In either case, the party receiving the proposed form of written contract should acknowledge the significance of that document by treating it cautiously and, at the first opportunity, either identifying particular concerns with that document or reserving their rights in respect of that document. Agreements purportedly reached on misunderstandings about what was believed to be accepted on standard form documents can constitute time bombs in developing relationships.


Precedent (or form) documents are valuable stores of knowledge. However, if used, their content must be checked for their application to the particular transaction at hand. Another disadvantage is that, depending upon the context of their use, precedent documents are usually perceived by the party being asked to sign them as being so one sided as to be commercially unrealistic. A properly conducted negotiation should remove, or reduce, this perception.


The written contract should be the key reference document and incorporate all aspects of the commercial relationship (for example, project plans, service level agreements, pricing schedules and the like). This is particularly relevant in dealings between parties in different countries with different legal systems, languages and customs.




A prerequisite to implementing the Contract Process is to allocate responsibility for delivering a written contract. Ideally, this person (often called a contract manager) is an individual separate from the project manager and the client relationship manager. This demarcation allows the resolution of issues to be escalated to people with a horizon perspective of:

  • the business as a whole, and
  • the relationship with the other party.


Depending upon the skills of the contract manager, a lawyer will also be useful. The lawyer can assist in recording the commercial agreement, identifying the contingencies which may occur over a course of a commercial relationship and, of course, advising about the effect of the law.


In each case, the people responsible for producing the written contract should:

  • be given a clear understanding of the commercial goals, and
  • have a good understanding of what is market.


In any event, the contract must be owned by all individuals working on the project. If the written contract is captured legally so that the parties at the operational level do not understand it, or accept its content, then it has not achieved its purpose. The written contract should be treated as much as a project deliverable as any other product.




In the information technology context, parties often leave agreeing, and executing, a written contract too late in the course of their satisfying the substance of the relationship. Ideally, the completion of the written agreement should be completed before the provision of products or services commences. A well drafted contract can deal with all reasonably foreseeable contingencies that arise during the course of a project.


However, if this ideal approach is not accepted (usually because commercial parties have experienced contract negotiations dragging on and have not applied a Contract Process such as that suggested below with strict adherence to a realistic time table), the parties should agree that a Contract Process apply simultaneously (and fast tracked) with the other actions occurring in the parties' relationship. This latter approach is only realistic if there is, at least, agreement about key points (such as time, price, quality and quantity). Alternatively, the parties may agree the performance of certain well defined first stage or initial tasks, for a fixed price, with the balance of the project only being committed to on the signing of the contract.


Timing for completing the steps in the Contract Process should be realistic so that expectations are reasonable. In setting the timetable, project managers need to acknowledge the competing pressures on participants' time and establish the priority of the Contract Process in relation to the other actions in the project.


Contract Process



  • First, the parties (at the, say, project sponsor level):
    • agree the process (such as this one) for the delivery of a written contract
    • set a timetable by which each task should be completed, and
    • allocate responsibility for preparing the drafts of the contract (it is commonly perceived to be a slight advantage to control the drafting)
  • Second, the parties identify the principal commercial and legal issues that:
    • have been agreed, and
    • remain to be agreed
  • Third, responsibility for reaching agreement about the principal commercial and legal issues is allocated together with protocols for escalating road blocks
  • Fourth, the responsible people negotiate agreements about the outstanding issues
  • Fifth, on the basis of the agreements reached, a first draft of the contract is prepared
  • Sixth, there is a high level discussion of the first draft
  • Seventh, further drafts of the contract are prepared, reviewed and negotiated
  • Eighth, outstanding issues are escalated for resolution
  • Ninth, final draft prepared and signed
  • Tenth, conditions precedent are satisfied and the contract comes into effect.


The content of this document is necessarily general and readers should seek specific advice on particular matters and not rely solely on this document.
If you would like further information on any of the topics in this document, please contact the writer or your usual Auld Brewer Mazengarb & McEwen adviser.


Return to previous page Print