Chapter 12 - Statements of Work for IT Procurements

12.2 Preparing a quality IT statement of work (SOW)

Once the project scope is completed, the project team will build the SOW, which is the basis for a supplier’s proposal response and contract performance. Including a SOW in the solicitation gives each supplier the information from which to prepare its offer. Since the winning supplier will perform the contract following the requirements in the SOW, it is critical to include and state all technical, functional, performance and project management requirements and expectations clearly and without ambiguity in the SOW. VITA SCM provides a SOW template and SOW Change Order template for authorized users to use when ordering from a VITA statewide contract at this location under the section called “Tools:” https://www.vita.virginia.gov/procurement/policies--procedures/procurement-tools/. This template and the guidance in this chapter are best practice recommendations. You may use the template, the following guidance, or any combination—as best suited for the size and complexity of your procurement. IT projects that require CIO approval and/or VITA oversight will require following Commonwealth Project Management standards and policies provided at this URL: https://www.vita.virginia.gov/policy--governance/project-management/project-management-division-pmd/.

The SOW must be written as a concise, declarative document as it is a statement of the agency’s requirements and the supplier’s performance commitment. In non-performance- based SOWs the supplier may be required to perform the work in a specific way, using detailed specifications, specifying key personnel to be provided and methods to be used for service contracts. A well-written SOW should:

Be a stand-alone document.
Be crafted in a general-to-specific fashion.
Be an expansion of detail tailored from the requirements definition results and the approved scope statement and free of inconsistencies and/or conflicting requirements.
Be individually tailored to consider the period of performance, deliverable items, if any, and the desired degree of performance flexibility.
Not repeat material that is already included in other parts of the solicitation/contract.
Describe in detail what the supplier is to accomplish through addressing the following four elements:
- What is to be done and what are the deliverables/milestones?
- Who is going to do what (agency, supplier, third party CoVA agent, etc.).
- When is it going to be done by deliverable and/or milestone?
- Where will it be done?
- How will it be done and how will the agency know when it is done (i.e., testing and acceptance)?

The SOW content and detail will depend on the nature of the procurement and can range from extremely simple—buying packaged software—to extremely complex—procuring a solution or system design. The needs assessment/requirements definition/specifications development details (refer to Chapter 8) should be duplicated in certain relevant areas of the SOW. All SOWs should minimally include the following components:

Introduction—a general description of the procurement.
Background—information that helps suppliers to understand the nature and history of the agency, the project, the audience being served and the purpose of the new requirements. When applicable, include the current and desired technology environment (architecture) and interfaces with graphic and textual descriptions.
Scope—overview of the SOW that relates the parameters and important aspects of the requirements, taken from the scope statement.
Applicable directives (if any)—referenced documents, standards, specifications or directives that are either mandatory or informational for the procurement.
Performance requirements—what is required to be accomplished, the performance standards and the acceptable quality levels.
Deliverable requirements—Technology products, services, software, project and other reports, testing and all deliverables and formal requirements that must be submitted by the supplier during the contract.
Quality assurance and acceptance criteria—Acceptance is the agency’s formal, written process to acknowledge that the deliverables conform to applicable contract quality, quantity and other requirements. Acceptance may or may not involve quality assurance processes and typically precedes payment. The procedure for formal acceptance should be provided for any milestone deliveries, as well as final acceptance.

Below is a comprehensive list that provides a selection of considerations for SOW content ranging from simple to complex procurements—from a single IT component to a major systems design. The project team may glean useful reminders from this list even though all of them may not be pertinent to a particular procurement. Many of the details may be pulled from the requirements definition document to ensure completeness and accuracy.

Depending on the project’s size, complexity, delegation and approval thresholds, the business owner must ensure compliance with any Commonwealth Project Management standards and requirements for building SOWs, located at this URL: https://www.vita.virginia.gov/policy--governance/project-management/project-management-division-pmd/.

Introduction	This is a general description of the procurement.
Background	Provide information on the agency, the project/program and/or the services that are affected by this procurement. Include graphics of the user environment/flow of information/current business and operating environment.
Scope statement	Retract from the scope statement prepared in step 2 of this process.
Summary of technical, functional and performance objective(s)	Provide a general description of these objectives.
Summary of technical, functional and performance requirements	Provide a general description of these requirements including all desired solutions, products and/or services.
Specific technical, functional and performance requirements	Specific and detailed requirements must be fully described and include desired agency operating architecture/user environment, if known. If supplier will provide this as part of their proposal, then these requirements will be negotiated and finalized as the contract’s definitive SOW exhibit. These would include all technical and functional requirements for all software and hardware, the solution and/or the system being procured and include any related services. If requirements development/system design is a deliverable, then this would be finalized prior to final development, implementation and testing and would become a separate deliverable under the SOW.
Requirements development	If this is part of what the supplier will do, so state and include references in the project’s milestone schedule and the deliverables listing.
Custom development and test system environment	Same as previous item
Business design and technical design	Same as previous item
Interface/ integration/legacy systems requirements	Same as previous item. The solicitation must provide all known information about these so suppliers can sufficiently estimate and propose an approach and these requirements should be included in the final contract’s SOW, milestone schedule and list of deliverables.
Data conversion	The agency should know and relay the condition of data that requires conversion. Typically, this can be a high cost and/or performance risk vulnerability area.
Bill of material	List all components of software and hardware and expected delivery dates
Testing	Include requirements for any installation, configuration, system, functional, product, beta/production testing and final acceptance testing. Consider carefully the testing duration and environment to emulate a true-to-life test.
Acceptance criteria and acceptance procedures	Include specific acceptance criteria for all deliverables from paper reports to final system turnover. It is advisable to define the agency approval time, supplier resubmit time and so on. Make sure that no conflicting information is provided here and/or in the actual contract language.
Risk management process	Include written requirements/procedures for contract duration and enhance frequency and risk areas (cost, schedule, design/development, interface, etc.) for monitoring/reporting depending on the complexity of the procurement. Written reports/deliverables may also be required. Establishing an escrow account may also be necessary for protecting ongoing use of supplier software in the case of supplier bankruptcy or other business change that could interrupt business continuity.
Quality control/assurance requirements	Describe all requirements for quality control by the supplier, quality assurance and monitoring by the agency or an independent IV&V resource, including all required plans, scheduled reporting and details around the how and when of metrics capture/validation. See Chapter 21 of this manual for an entire discussion of performance-based contracting and service level agreements.
Configuration/change management/engineering decision traceability requirements	Describe/list all required schematics, engineering drawings, plans, documents and other traceability deliverables to continue agency operational independence if necessary and to capture historical experience for future reference.
Project management requirements	Depending on the complexity of the procurement, these requirements can be simple or severe. Project management responsibilities can be shared between agency and supplier or performed by only one of the parties; however, it should be clearly stated. Certain Commonwealth project management standards may be required for major projects and those requiring VITA oversight.
Training and documentation requirements	May include offsite or onsite training as best-suited for the agency’s budget. Include the number of participants, locations, type of training to be accomplished and all details as to trainer-led, train the trainer, classroom, computer or web-based, etc.
Meetings/reviews (design/project status/reviews)	Use for project control and to maintain project integrity and accountability. The supplier may or may not be required to attend; however, if they are they will include travel in their pricing. Virginia Department of Accounts per diem regulations do apply.
Maintainability and reliability and/or support and maintenance requirements	Include all requirements for maintenance and support while under warranty and for any out-years as budgeted and included in the contract. The related support services will normally be based on the supplier’s regular commercial offering, unless otherwise negotiated.
Performance/functionality requirements	Include fault isolation, min-max tolerance parameters, mean- time-between failures, environmental conditions, etc. Service level expectations and incentives for meeting them may be included and monitored, for full payment or established percentage reductions to the supplier as necessary to encourage successful performance.
Contract deliverables	List all hardware, software, system/solution, and paper deliverables such as QA/QC plans, configuration control plans, test plans, IV&V plans/reports, monthly status reports, risk assessment plans, project/milestone plans, GANTTs, etc. Include date due, quantity, any required format, media (paper, electronic, CD, DVD, etc.), when due, to whom/where for submission, days agency has to review/accept.
Standards/specifications/ directives	Include all required agency/VITA/COVA/federal, commercial or industry, standards for SEI process, IT accessibility/508 compliance, HIPAA, environmental, packaging, size, format, etc., and specify if these are available for viewing or included as attachments. Be sure to include any baseline drawings or specs, glossary of technical terms, organizational charts, etc. Be sure not to overlook or exclude relevant Commonwealth standards located at this URL: https://www.vita.virginia.gov/it-governance/itrm-policies-standards/
Govt. or supplier provisions	Specify any equipment, facilities, materials and resources that will be provided by the Commonwealth to the supplier or vice versa for contract performance. Include provide-by dates, transmittal requirements and return procedures.
Project schedule requirements/period of performance	Provide overall term and a milestone schedule (or request a proposed one from suppliers that will be included in any resultant contract) with expected or definite dates (calendar or “days after award”). Take project planning and milestone to the lowest level to best monitor performance status. Consider any project dependencies that may affect milestones and the overall schedule.
Place of performance	If other than supplier location, state the locations and percentage of time at offsite premises; include meeting attendance for supplier. If performance to take place at VITA or other authorized user location, be specific in expectations for attendance, background checks, office access, etc.
Special/key personnel requirements	If a requirement is in the solicitation for supplier to provide resumes of key personnel, these individuals can be named in the final negotiated SOW with a requirement for agency written approval for any replacements during the contract term. Include all this language then in the solicitation. If certain personnel are key to project success, name them specifically and designate how they will be replaced and when if they leave the project for any reason.
Pricing type	Identify that performance will be based on time & material and/or fixed price; however, the actual pricing schedule will be a stand-alone exhibit to the contract.
Technical point(s) of contact	Provide the names and contact information for the designated project managers and/or technical representatives, updating by contract modification as necessary during contract performance.
Any special warranty requirements	Make sure these do not duplicate any general warranty terms placed elsewhere in the contract document.
Security and/or access requirements	Include all agency/VITA/Commonwealth physical access and data access (hardcopy and electronic) and hosting requirements. VITA security requirements are located at this website: https://www.vita.virginia.gov/it-governance/itrm-policies-standards/ and reference to it should be included in the SOW, if applicable to the IT procurement. Dialogue with your VITA AITR/Project Management representatives regarding this is crucial to building any of these requirements.
Enterprise Cloud Oversight (ECOS) Requirements	Check the VITA statewide contract being used to issue this SOW. If it is not a Cloud Services or Software as a Service (SaaS) contract and does not include required Cloud/SaaS terms, or if the contract scope does not authorize and the product list does not include SaaS products, contact scminfo@vita.virginia.gov before going any further to determine next steps. If the contract does include the required Cloud/SaaS terms, contact enterpriseservices@vita.virginia.gov to determine if the particular SaaS product has been ECOS approved or not and to determine next steps.

Current chapter: Chapter 12 - Statements of Work for IT Procurements
Previous < | > Next

Chapter 11 - IT Procurement Planning and Strategic Sourcing < | > Chapter 13 - The IT Procurement Project Team

Search the manual by key words or common terms.