Your browser does not support JavaScript!

Chapter 25 - IT Contract Formation

25.4 Forming an IT contract

25.4.2 General guidelines for a successful IT contract

The key to success in forming any IT contract is setting and meeting the agency's business needs and project's expectations. This can be accomplished by the designation of a joint steering committee to manage the contract's success; identifying individuals for both parties who will have responsibility for the project; continual dialog and open discussion of problems; keeping the contract up-to-date with an effective change-control process; and requiring the supplier to provide early and frequent progress reports in order to minimize the potential for surprises. According to IT contract experts, most IT contract troubles result from one of the following scenarios:

  • Supplier makes unrealistic commitments (e.g., performance guarantees, unachievable schedules, fixed price contracts without the required analysis) or supplier underestimates labor time, costs, risks.

  • There is no firm contractual baseline (e.g., unclear requirements, terms and conditions and statements of work) in the contract.

  • The supplier does not manage the agency relationship (i.e., the working relationship must be continually enhanced and problems must not be hidden).

  • The contract does not contain a procedure and process for managing change (i.e., no formal change management process).

The following industry best-practice considerations should be used when forming an IT contract:

  • A successful IT contract will include all technical and administrative expectations and commitments from both parties. The contract should include procedures for quality reviews, testing, measurement of progress, performance capture and reporting, defect management, change request processing, upgrades and problem escalation. The agency should consider its needs with respect to supplier reliability, performance, functionality, compatibility, lifespan, security compliance, support and cost.

  • In order to reduce the likelihood of failure, the contract should be as specific as possible. Contract failure can be avoided by making sure both sides agree upon a common, written set of definitions, specifications, and time tables with regards to the services or systems being procured. As questions and issues arise, both sides can refer to and, if necessary, revise the document.

  • The supplier looks to define its contractual obligations while the agency seeks to solve business issues. To deal with this difference in perspectives, the contract should include conflict and change provisions. For instance, the contract agreement might call for monthly meetings to review performance, problems and successes. This encourages supplier management and helps the parties deal with issues before they become major problems.

  • The agency should monitor all IT contracts carefully, especially contracts for IT services. In most IT contracts, there is a service or support element involved, and suppliers should be held to their performance/response time contractual guarantees and promised service levels beyond the initial implementation period. If the supplier is not providing adequate service or not meeting agreed upon service levels, if the product is not operating as promised, or if the agency usage is not as high as anticipated, the agency may receive a partial refund or request a credit or higher discount.

  • There is an advantage in agreeing to a detailed service level agreement (SLA) that confirms what exactly supplier responsibilities are under the contract. A good SLA will reflect common sense project discussions and seek a balance of interests and incentives.

  • Pricing should adapt to certain contract changes, for example, changes in services, optional services and revised or unmet SLA. Another adaptive price modality would include subscription-based services as in Software as a Service procurements where pay-as-you-go pricing (or scalable pricing) should be included in the pricing so that agencies only pay for the actual number of users of the service. If contract prices are fixed over a period then price increases, and sometimes decreases, may need consideration. Agencies should seek to limit increases to the rate of inflation and can even include a cap; i.e., +/-3% of the CPI.

  • Both parties should contractually agree to specific expectations, promises, and contingencies. For example, system specifications should include not just the required functionality, but should also spell out any performance requirements or constraints, compatibility requirements, anticipated lifespan, and acceptable levels of defects.

  • Both parties should clearly and unambiguously define key terms, conditions, and activities such as the meaning of "beta testing" or the standards for determining whether the agency has accepted the system. In the IT world, accepting a system can occur at many different times, such as when it has passed a series of agreed-upon tests ("acceptance testing") and has been in operation for a certain period of time with no serious defects. If all parties are not willing to define acceptance, that's a strong warning sign that a dispute may emerge. However, the exercise of creating an SLA may flush out potential problem areas well in advance of any signing, payment, or delivery.

  • All time references should be specific dates. Avoid the use of "reasonable time" or "promptly" and be specific in each party's requirements under the contract. i.e. "within three days after (some point in time; i.e., contract award date)."

  • If formulas are used within the agreement, make sure that they work.

  • Do not use vague references such as "prepared to our satisfaction," "in a timely manner," "would reasonably be expected to." It is difficult to determine when a supplier "has performed in a timely manner."

  • Avoid using words like "materiality" and "solely" unless definitions are included.

  • Carefully select use of the words "shall" (mandatory) and "may" (permissive).

  • If the contract is defined as "high risk" pursuant to 2.2-4303.01 of the Code of Virginia, the contract must contain distinct and measurable performance metrics and clear enforcement provisions, including penalties and incentives, to be used in the event that contract performance metrics or other provisions are not met.

Finally, VITA recommends that all contract documents go up and down the chain of command in both parties' organizations as needed to make sure all relevant personnel understand what is promised and what is expected and that the final contract includes all. Additionally, VITA's Project Management and Oversight Division provides standard Commonwealth project-related templates and tools, including a Technology Management Glossary, for IT-based terminology to drive consistency throughout the Commonwealth. (Visit:

Search the manual by key words or common terms.