Statement of Work Template for Software Development

Document ID: SOP-TR-OPS-409
Effective Date: October 24, 2023
Version: 3.1
Review Cadence: Semi-Annual

---

1. Executive Summary & Scope

1.1 Purpose

This Standard Operating Procedure (SOP) defines the institutional requirements, governance protocols, and procedural lifecycle for authoring, validating, and executing Statements of Work (SOW) for custom software development engagements within Template Registry operations. Adherence to this protocol mitigates scope creep, establishes deterministic acceptance criteria, and enforces legal-technical alignment between engineering capacity and client deliverables.

1.2 Scope

This SOP applies to all internal Engineering, Product, Legal, and Account Management divisions. It governs any custom software development project initiated under a Master Services Agreement (MSA) or standalone contract exceeding 160 billable hours or $20,000 USD in contract value.

---

2. Prerequisites & Required Tools

2.1 Required Tools & Access

• Template Registry SOW Repository: Access to the enterprise document management system (Confluence/SharePoint) for baseline template retrieval.
• Version Control & Project Management: Jira Software and GitHub Enterprise for milestone mapping and technical task estimation.
• Legal Review Portal: Ironclad or equivalent Contract Lifecycle Management (CLM) software for compliance tracking.
• Estimation Framework: Parametric Software Estimation Tool (PERT) calculation spreadsheet (TR-EST-04).

2.2 Compliance & Standards

• ISO/IEC/IEEE 12207 (Systems and software engineering — Software life cycle processes).
• SOC 2 Type II data handling and IP indemnification compliance standards.
• Internal Template Registry Security Baseline Policy (SEC-POL-01).

---

3. Roles & Responsibilities (RACI Matrix)

Legend: R - Responsible, A - Accountable, Consulted, I - Informed

---

4. Step-by-Step Procedure

Phase 1: Requirements Discovery and Baseline Scoping

• 1.1 Convene kickoff meeting with the Client Stakeholder (CS) and Engagement Manager (EM) to capture business objectives, functional requirements, and non-functional constraints.
• 1.2 Populate the Requirement Traceability Matrix (RTM) using the Template Registry repository format (TR-RTM-v3).
• 1.3 Conduct cross-functional feasibility assessment with the Technical Architect (TA) to validate tech stack compatibility and integration dependencies.

Phase 2: Architectural Mapping and Deliverable Definition

• 2.1 Define high-level system architecture, data flow diagrams, and external API dependencies.
• 2.2 Break down system requirements into distinct, measurable deliverables using Epics and User Stories in Jira.
• 2.3 Establish explicit "Definition of Done" (DoD) criteria for each milestone, incorporating code review standards, unit test coverage minimums (e.g., $\ge 80%$), and CI/CD pipeline deployment success.

Phase 3: Estimation, Pricing, and Timeline Modeling

• 3.1 Execute 3-point estimation (Optimistic, Most Likely, Pessimistic) for all Jira Epics using the internal PERT model.
• 3.2 Calculate total project budget, accounting for engineering velocity buffers (standard coefficient: 1.15) and contingency reserves (minimum 10%).
• 3.3 Construct the Milestone Payment Schedule tied strictly to tangible, demonstrable software releases (e.g., Alpha, Beta, Production Release).

Phase 4: Legal Framework and SLA Integration

• 4.1 Embed standard intellectual property (IP) assignment clauses ensuring full client ownership upon final payment settlement.
• 4.2 Define service level agreements (SLAs) for post-deployment warranty periods (standard: 30 days bug-fix warranty).
• 4.3 Submit draft SOW to Legal Counsel (LC) via the CLM portal for compliance validation against the Master Services Agreement (MSA).

Phase 5: Authorization and Execution

• 5.1 Route validated SOW through EM and Client Stakeholder for formal review.
• 5.2 Execute digital signature collection utilizing certified platforms (DocuSign/Adobe Sign).
• 5.3 Archive executed SOW in the Template Registry ERP and trigger Jira/GitHub workspace provisioning.

---

5. Quality Assurance & Verification

5.1 Key Metric Thresholds

• Estimation Variance: Final engineering hours must not exceed $\pm 10%$ of the SOW baseline without a formal Change Request (CR).
• Deliverable Clarity Score: 100% of milestones must feature binary pass/fail User Acceptance Testing (UAT) scripts.
• Legal Turnaround: Initial legal review must be completed within 48 business hours of submission.

5.2 Common Pitfalls to Avoid

• Vague Acceptance Criteria: Utilizing subjective terminology such as "user-friendly" or "high performance" without quantifying metrics (e.g., "Page load time $< 1.5$ seconds under 500 concurrent users").
• Out-of-Band Assumptions: Failing to document third-party API dependencies or client-side resource availability constraints.
• Implicit Maintenance: Confusing project-based custom development delivery with ongoing Software-as-a-Service (SaaS) operational support.

5.3 Audit Checklist

• Does the SOW reference the correct underlying Master Services Agreement (MSA)?
• Are all out-of-scope items explicitly listed in an "Exclusions" section?
• Is the payment schedule unambiguously linked to quantifiable milestone deliverables?
• Have both technical and legal leads signed off on the document payload?

---

6. Troubleshooting FAQ

Q1: The client demands an unbudgeted feature mid-project execution. How is this handled procedurally?
A1: Stop verbal negotiation immediately. Invoke SOP-TR-OPS-410 (Change Request Protocol). Draft a formal SOW Amendment specifying the additional cost, revised timeline impact, and updated resource allocation. Work must not commence on the new feature until the SOW Amendment is executed by both authorized signatories.

Q2: The client fails to provide necessary third-party API access credentials, delaying Milestone 1. What is the operational remedy?
A2: Immediately log the dependency blockage in the project risk register. Issue a formal written notice to the Client Stakeholder referencing the timeline impact clause. Project delivery timelines and milestone deadlines automatically extend day-for-day based on client-side latency, protected by the dependencies section of the SOW.

Q3: How should disputes regarding "Acceptance Criteria" be resolved when a client rejects a delivered milestone?
A3: Refer directly to the binary UAT script defined in Section 4 of the executed SOW. If the build passes the automated and manual test scripts defined in the baseline document, the deliverable is deemed accepted. Any functionality requested outside those written parameters must be queued as a separate change order.