Statement of Work (SoW)
Template — South Africa

Sets the strategic context for the engagement, including the business problem the project addresses, high-level objectives, success criteria, and the relationship between this SoW and the governing MSA. It identifies the SoW number and version, the MSA it operates under, the effective date, and the estimated project duration. This section is essential for contract interpretation — under the Endumeni approach adopted by South African courts, the purpose and context of the agreement inform the interpretation of its specific provisions.

Provides a comprehensive description of the services to be performed and the deliverables to be produced. Critically, it includes explicit "out-of-scope" exclusions that define the boundaries of the engagement, preventing scope creep by clearly documenting what is not included. Each deliverable is described with sufficient specificity to enable objective assessment of whether it has been completed. The scope section should be detailed enough that a replacement service provider could understand what needs to be delivered without additional context from the original parties.

Establishes the project schedule with defined milestones, delivery dates, dependencies between phases, and the consequences of delays caused by either party. Dependencies include client-side obligations (providing access, approvals, test data, feedback within agreed timeframes) and third-party dependencies (vendor integrations, regulatory approvals). The section addresses the impact of client-caused delays on the provider's delivery obligations, typically providing for an equivalent extension of delivery dates plus any reasonable remobilisation costs. South African courts hold both parties to their contractual obligations — the client cannot claim breach for late delivery if the delay was caused by the client's own failure to meet dependencies.

Lists each deliverable with specific, measurable acceptance criteria against which the deliverable will be assessed during the acceptance process. Acceptance criteria should be objective and verifiable — not subjective judgments like "to the client's satisfaction." The section defines the review period (typically 5-10 business days), the process for submitting acceptance or rejection with written reasons, and the remediation cycle for rejected deliverables (typically two remediation attempts before escalation). Under CPA Section 56, deliverables must be of good quality and fit for their intended purpose — the acceptance criteria define what this means in the specific project context.

Identifies the key personnel assigned to the project from both the provider and client sides, their roles and responsibilities, the process for replacing key resources (typically requiring client approval for senior roles), and the RACI matrix (Responsible, Accountable, Consulted, Informed) for project activities. Client-side responsibilities are particularly important — the SoW must clearly document what the client is expected to provide (access to systems, subject matter experts, test environments, content, approvals) and the impact on the project if these responsibilities are not fulfilled. This bilateral obligation structure is critical for defending against breach claims in South African courts.

Defines the project pricing structure — fixed-price, time-and-materials, milestone-based, or a hybrid approach. For milestone-based payments, payment triggers are tied to the acceptance of specific deliverables, not merely their submission. The section covers VAT treatment at the standard rate of 15%, expense reimbursement policies, the invoicing process, payment terms (referencing the MSA's standard terms, typically 30 days), and any project-specific pricing variations from the MSA rate card. For time-and-materials engagements, the section includes estimated effort, rate cards, and any fee caps or not-to-exceed amounts.

Establishes the formal procedure for managing scope changes during the project. When either party identifies a change requirement, a written Change Order must be raised documenting the modified scope, impact on timeline, impact on cost, and any changes to acceptance criteria. Both parties must approve the Change Order through authorised signatories before additional work commences. The provision explicitly states that no out-of-scope work will be performed or compensated without a signed Change Order. This is critical under South African common law, where the non-variation clause (as upheld in SA Sentrale Ko-op v Shifren) gives contractual force to the requirement for written variations.

Documents the key assumptions underpinning the SoW — technical assumptions, business assumptions, resource assumptions, and environmental assumptions. If any assumption proves incorrect, the section provides a mechanism for reassessing scope, timeline, and pricing through the change control process. Constraints (budget limitations, technology restrictions, regulatory requirements) and identified risks (with mitigation strategies and risk owners) are also documented. In South African contract law, assumptions can be critical to the enforceability of the agreement — if a fundamental assumption is incorrect, the doctrine of mistake (as explored in Sonap Petroleum v Pappadogianis) may affect the contract's validity.

Defines the testing methodology, test environments, test data responsibilities, and quality assurance processes for the project. For IT and software projects, this includes unit testing, integration testing, user acceptance testing (UAT), and performance testing requirements. For other service types, it covers the quality review process, peer review requirements, and compliance verification. The section establishes who provides the test environment and test data (typically the client), the provider's obligation to deliver defect-free deliverables for acceptance testing, and the process for logging and resolving defects discovered during testing.

Establishes the project governance structure including steering committee composition, decision-making authority, escalation procedures, and the schedule for project status meetings. It defines the communication framework — progress reports, status dashboards, meeting cadence, and the tools to be used for project management and collaboration. The section identifies the authorised representatives for each party who can approve deliverables, sign Change Orders, and make binding decisions on behalf of their organisation. Clear governance prevents the informal decision-making that leads to scope disputes in South African service engagements.

Defines what constitutes project completion (typically the acceptance of all deliverables and the resolution of all critical and major defects), the handover process for transferring deliverables and documentation to the client, and the knowledge transfer activities required to enable the client to operate and maintain the deliverables independently. For IT projects, this includes source code handover, technical documentation, deployment guides, and administrator training. The section also addresses the provider's obligations during a warranty or defect liability period following project completion (typically 30-90 days), during which the provider resolves any defects in accepted deliverables at no additional cost.