Statement of Work (SOW) Process

While a Statement of Work is unique for each project, the SOW elements are generally consistent across projects.

Basic Elements include:

• Scope of Project
• Roles and Responsibilities
• Deliverables
• Period of Performance/Schedule
• Service Levels
• Acceptance Criteria

Additional SOW Elements to consider per project include:

• Security standards
• Accessibility compliance
• Introduction and Background
• Evaluation and Response Submission Requirements
• Additional Customer Terms and Conditions
• Transition Plan
• Other considerations – DCS; Hosting; Disaster Recovery Plan
• Award – will it be a single award or multiple vendors
• Eligibility requirements
• Qualifications
• Additional Terms and Conditions - Customers may include additional requirements so long as they do not conflict or weaken the terms and conditions of the DIR master contract. These items, while not mandatory, should be reviewed to ensure they are applicable and do not conflict with proposed DIR Contracts or statute.

Statement of Work Reviews do not apply to:

• Shared Technology Services Program
• Communications Technology Services
• Managed Services for Telecommunications contracts have a separate review process for approval of SOW.

State agencies submit their Draft and Final SOWs to DIR for review and approval through the DIR SOW Portal. Register and log into the SOW Portal through the DIR Applications Portal page.

Each agency submitter will have a unique login to access the SOW Portal. Submitters are identified as either:

• Submitter - The submitter will only have access to the SOWs that they submitted; or
• Superusers - A superuser will have access to all the SOW's for their agency

To Add/Remove/Modify an SOW Portal User, the agency's Superuser sends an e-mail to [email protected]. Be sure to include in the request Agency name, contact name, phone, e-mail address, and indicate if the role to create will be Superuser or Submitter.

Deliverables based SOWs have traditionally followed the Waterfall project methodology that adheres to a fixed scope. However, not all SOWs are suited to Waterfall and agencies may want to consider the more iterative approach of the Agile project methodology.

Waterfall (Traditional) Methodology

Works well with projects that have assured predictability. The emphasis is on time and budget.

• Assured predictability
• Scope determined and fixed
• Complete project planned up front
• The final product is delivered to customer for approval
• Follows a linear path working from high-level to low level
• Challenges:
  • Projects become rigid and resistant to change
  • Focus is sometimes more about the process than the product of service being delivered
  • Significant amount of up-front analysis
  • Early sign off on requirements that might not be fully understood
  • Cost can be high due to extra effort spent fixing defects and having to rework design

Agile Methodology

The Agile Methodology is based on iterative development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

• Planning done as needed
• Negotiate requirements
• Working product with progressively increasing functionality can be shared with customer after each iteration
• Ability to respond to change is high
• Inspect and Adapt is an agile best practice used to capture the idea of discovering emergent requirements
• Working product is the primary measure of progress.
• Working product with progressively increasing functionality can be shared with customer after each iteration.
• Challenges:
  • Changing the team structure can negatively impact the project
  • Organizational buy in to the methodology
  • Changes in scope probable
  • Need for subject matter experts (SME) on the project team