Desktop version

Home arrow Computer Science

  • Increase font
  • Decrease font

<<   CONTENTS   >>

Technical Environment

Depending on the engagement, it may be important to describe in detail the technical environment in which the services will be rendered or in which the deliverables are expected to operate.

■ Define the hardware and software requirements of the project.

■ Identify relevant applications.

■ Define required interfaces, data formats, and connectivity requirements.

■ Specify any other relevant systems and interfaces.

Acceptance Testing

Acceptance testing ensures the services and deliverables conform to the customer’s expectations, which are described in detail in the body of the SOW. While the agreement will generally include language defining the procedure for acceptance testing (e.g., when and how acceptance testing will be conducted, procedures for addressing nonconformances, and remedies for failed acceptance testing), the SOW provides the specifics of the testing or the acceptance criteria.

■ Tire period of acceptance testing and the acceptance criteria should be identified. The goal is to objectively define all criteria by which acceptance is to be measured. While acceptance tied to the customer’s “reasonable satisfaction” is certainly useful, it would require a lawsuit to determine the meaning of that requirement. It is better to clearly and objectively define acceptance criteria than to use subjective language that may give rise to disputes.

■ Include staged acceptance where relevant (e.g., initial installation acceptance, system integration acceptance, end user acceptance, final system acceptance).

■ Include final, overarching acceptance where relevant.


Deliverables are the specific items that the contractor is expected to create and deliver as a result of the services. They can be pieces of software, hardware components, or items of documentation.

■ What will be delivered and when? Create several of these milestones throughout the life of the project.

■ In what form/format will the deliverables be provided?

■ Payments should be tied to objective milestones and deliverables, not only date-based terms.

■ Be aware of language that shifts all of the risk associated with a delay in the project to the customer. For example, if the contractor requires input or other items from the customer, the customer’s failure to deliver those items on time should not create an “out” for the contractor unless the contractor expressly informs the customer of the delay and the likely consequences of the delay. Using this approach allows the customer to control the timeline and forces the contractor to take a proactive approach to managing project timelines, thereby reducing the chance of unwelcome surprises for the customer.

■ Documentation should be provided for all deliverables. The description of each deliverable should be specific and detailed enough that in the event of early termination of the SOW, for whatever reason, the work to-date can be leveraged.


In certain engagements, it will be important for the contractor to deliver documentation (e.g., user guides, software flow charts, specifications) as part of the deliverables. Documentation should be clearly written and understandable by the audience for which it is intended.

■ What will be provided to the contractor?

■ What is expected from the contractor?

■ In what format will documentation be provided?

■ Delete all legal terms included in contractor-provided documentation. Only the agreement should contain legal terms unless specifically agreed otherwise by the customer’s lawyers.

Roles and Responsibilities of the Parties

Few professional service engagements require the services of only the contractor. In most instances, the customer will also be assigned tasks to perform. Frequently, the customer tasks will be written as contingencies on the contractor’s ability to perform.

■ Specify names, titles, and roles for each member of the customer team.

■ Specify names, titles, and roles for each member of the contractor team.

  • - Identify any key contractor team members (e.g., the contractor’s project manager). Include language limiting the contractor’s ability to replace key team members.
  • - Where relevant, include incentives to ensure consistency of the contractor’s team (e.g., a credit if attrition exceeds a defined percentage of the team, which is particularly relevant in offshore engagements where staff turnover is frequently very high).

Project Management Processes

In any project lasting more than a few days, it is important to detail the methods by which the project will be managed to ensure schedules and budgets are achieved and services performed properly.

■ What project management tool, if any, will be used?

■ Frequency and types of reports. Define content and metrics (service level agreements, budget, milestones, etc.) for the reports.

■ Project plan (activities, resources, timeframes).

■ Ensure all relevant dates are properly calendared and tracked.

■ Progress reports (include tasks completed that week, to be completed the following week, issues and status of deliverables, timesheet, etc.). Agree on the form of the reports.

■ Method of updates (meetings, conference calls, video conferences, etc.).

<<   CONTENTS   >>

Related topics