Test And Accept
Concepts

Statements of Work

Defining and managing project deliverables

A Statement of Work (SOW) is a detailed document that outlines what will be delivered for a project. Think of it as a contract between you and your client that specifies exactly what you'll build, how it will be tested, and who needs to approve it before it's considered complete.

What is a Statement of Work?

Statements of Work help you:

  • Define Scope: Clearly document what you're building and what's included
  • Track Progress: See how much work is complete and what's remaining
  • Manage Approvals: Get sign-off from clients and stakeholders
  • Maintain History: Keep a record of changes and decisions over time
  • Organize Deliverables: Break down complex projects into manageable pieces

SOW Properties

Every Statement of Work has the following information:

Basic Information

  • Title: A clear, descriptive name for the SOW (e.g., "Mobile App Development - Phase 1")
  • Description: Detailed explanation of what the SOW covers and any important context
  • Project: Which project this SOW belongs to (optional but recommended)
  • Organization: Your company or team that owns this SOW
  • Owner: The person responsible for this SOW
  • Due Date: When this work needs to be completed (optional)

Status

Your SOW will be in one of four states:

  • Draft: You're still working on defining the scope and requirements
  • Pending Approval: You've submitted it for review by stakeholders or clients
  • Approved: Everyone has signed off and you can begin work
  • Rejected: Stakeholders declined approval and it needs revision

Organization Features

  • Version Number: The current version of this SOW (starts at 1)
  • Primary Contact: The main client contact for approvals and questions
  • Pinned: Mark important SOWs to keep them at the top of your lists
  • Archived: Moved to archive when complete or no longer needed
  • Created/Updated: Timestamps showing when it was created and last modified

How SOWs are Organized

A Statement of Work contains a hierarchical structure that breaks down work into manageable pieces:

What Goes in a SOW?

  1. Work Items: The tasks, requirements, and deliverables that need to be completed
  2. Acceptance Criteria: The specific conditions that must be met for each item to be considered done
  3. Tests: Verification procedures to confirm the criteria are satisfied
  4. Versions: Historical snapshots of the SOW as it changes over time
  5. Approvers: People who need to review and approve the SOW

Working with Statements of Work

Creating a New SOW

When you create a new SOW, you'll need to provide:

Required:

  • A descriptive title that clearly identifies what this SOW covers

Recommended:

  • A detailed description of the scope and objectives
  • The project it belongs to
  • A due date for completion

The SOW will automatically:

  • Start in "Draft" status
  • Be assigned to you as the owner
  • Be version 1
  • Belong to your current organization

Copying an Existing SOW

If you're working on similar projects, you can copy an existing SOW to save time. When you copy a SOW, you can choose to include:

  • The work item structure
  • Test definitions
  • Acceptance criteria

The copy will start fresh with:

  • Draft status
  • No approvers (you'll add new ones)
  • Version 1
  • Today's date

Version History

Why Use Versions?

As your SOW evolves, you may need to make significant changes. Creating versions allows you to:

  • Preserve History: Keep a record of what the SOW looked like at different points
  • Track Changes: See what changed between versions
  • Revert if Needed: Go back to a previous version if necessary
  • Audit Trail: Show clients what was agreed upon at any time

What Gets Saved in a Version?

Each version captures a complete snapshot including:

  • The SOW title and description at that time
  • All work items and their structure
  • Acceptance criteria
  • Test definitions
  • Who created the version and when

When to Create a Version

Consider creating a new version when:

  • Making major scope changes
  • Before submitting for approval
  • After significant client feedback
  • At project milestones
  • Before starting a new phase of work

Approval Workflow

Setting Up Approvers

Before submitting an SOW for approval, you'll add the people who need to review and sign off on it:

Approver Properties:

  • User: The person who needs to approve (can be a team member or client contact)
  • Client Contact: Optional link to a specific client contact
  • Approval Status: Whether they've approved, rejected, or are still reviewing
  • Comments: Their feedback or notes about the approval (up to 1000 characters)
  • Approval Date: When they approved or rejected

The Approval Process

  1. Draft: Create your SOW and add all the work items, criteria, and tests
  2. Add Approvers: Select who needs to review and approve
  3. Submit: Change status to "Pending Approval"
  4. Review: Approvers review and either approve or request changes
  5. Completion: Once all approvers have signed off, status changes to "Approved"

Handling Rejections

If an approver rejects your SOW:

  • Read their comments to understand what needs to change
  • Make the necessary updates to the SOW
  • Consider creating a new version to track the changes
  • Resubmit for approval

Organizing Your SOWs

Viewing SOWs

You can view SOWs in several ways:

  • All SOWs: See everything in your organization
  • My SOWs: Only SOWs you own
  • Project SOWs: All SOWs for a specific project
  • Archived: SOWs that have been completed and archived

By default, archived SOWs are hidden to keep your lists clean.

Pinning Important SOWs

You can pin up to 3-5 critical SOWs to keep them at the top of your list. Pinned SOWs appear first, regardless of when they were last updated.

When to Pin:

  • Active SOWs you're currently working on
  • SOWs approaching their due date
  • High-priority client deliverables

Searching for SOWs

Use the search feature to find SOWs by:

  • Title keywords
  • Description text
  • Project name
  • Client name

Tracking Progress

Completion Metrics

Your SOW automatically tracks completion based on:

  • Items Progress (40% weight): How many work items are complete
  • Criteria Progress (30% weight): How many acceptance criteria are met
  • Test Results (30% weight): How many tests are passing

This gives you an overall completion percentage (0-100%) for the entire SOW.

What Progress Means

  • 0-25%: Just getting started, most work still ahead
  • 26-50%: Making progress, about halfway through
  • 51-75%: Good progress, entering final stages
  • 76-99%: Nearly complete, finishing touches
  • 100%: All items complete, all criteria met, all tests passing

Managing SOW Lifecycle

Archiving

When a SOW is complete or no longer needed:

  1. Archive the SOW to move it out of your active lists
  2. Archived SOWs are preserved with all their data
  3. You can unarchive if you need to access them again
  4. Archived SOWs don't count against completion metrics

Archive When:

  • The project is complete and delivered
  • The SOW has been canceled
  • Moving to a superseding SOW

Deleting

You can permanently delete an SOW, which will remove:

  • The SOW itself
  • All work items
  • All acceptance criteria
  • All tests
  • All versions
  • All approval records

Warning: Deletion cannot be undone. We recommend archiving instead.

Access Control

Who Can See Your SOWs?

Access to SOWs is controlled by:

  1. Ownership: You can always see SOWs you created
  2. Organization: Members of your organization can see all SOWs in that organization
  3. Project Access: If you have access to a project, you can see its SOWs
  4. Explicit Access: You can be granted specific access to individual SOWs

Permission Levels

  • Viewer: Can see the SOW and its contents
  • Editor: Can modify the SOW, add items, and update criteria
  • Owner/Admin: Can manage approvers, change status, and delete

Best Practices

Creating Effective SOWs

Do:

  • Use clear, descriptive titles
  • Link SOWs to projects for organization
  • Set realistic due dates
  • Add detailed descriptions
  • Create versions before major changes
  • Add approvers early in the process

Don't:

  • Create SOWs without linking to projects
  • Submit for approval before the SOW is complete
  • Make major changes after approval without creating a new version
  • Delete SOWs - archive instead

Typical SOW Workflow

  1. Planning (Status: Draft)

    • Create the SOW
    • Add work items and break down the scope
    • Define acceptance criteria for each item
    • Create tests to verify criteria

  2. Review (Status: Draft)

    • Get internal review from your team
    • Make adjustments based on feedback
    • Create a version before submitting

  3. Approval (Status: Pending Approval)

    • Add approvers (stakeholders/clients)
    • Submit for approval
    • Address any questions or concerns

  4. Execution (Status: Approved)

    • Complete work items
    • Run tests and verify criteria
    • Track progress

  5. Completion (Status: Approved → Archived)

    • Ensure all items are complete
    • Get final sign-off
    • Archive the SOW

Projects

Items

Acceptance Criteria

Tests