PMO-04.09.04 Phase 04: Planning

Statement of Work

بيان العمل

tasleemat asset PMO-04.09.04 template --lang en

Deliverable Summary & Governance Boundaries

Lifecycle Phase Alignment

Phase 04: Planning

Sizing Tier Requirements

Validation Contract

This deliverable conforms to a strict companion Draft 2020-12 JSON Schema for automated structural and semantic validation.

tasleemat validate PMO-04.09.04 ./completed_data.json

Template Markdown (Bilingual)

<!-- LLM INSTRUCTIONS: Fill in the [ Add details... ] placeholders
 based on project context.

Context and Definition:
A statement of work is the document that turns an agreement to buy something
into an obligation somebody can be held to. It says what will be delivered,
by when, to what standard, how acceptance will be decided, and - this is the
part most forms leave out - who may change it and how.

The distinction that matters is between a statement of work and a proposal. A
proposal describes work someone has offered to do. A statement of work
describes work someone has agreed to do, states the authority that agreed
it, and gives the parties a route to change it without either of them having
to break the contract. A document without the authority clause and the
change route is a proposal that has been filed in the wrong place.

It can receive information from:
*   The procurement strategy, which sets what will be bought and how
*   The project charter, whose objectives the work has to serve
*   The requirements documentation, so the statement of work describes the
    same scope the project is managing against

It provides information to:
*   The contract closeout report, which reads what was actually delivered
    against what was agreed here
*   The product acceptance form and the vendor performance scorecard, which
    both measure against the acceptance criteria set here
*   The procurement audit, which needs the agreed terms to test conformance

Tailoring Tips:
*   Write what is excluded. An omission reads as an inclusion, and the
    argument about scope almost always starts with something nobody said.
*   Name the standard rather than describing it. A named standard can be
    tested and can fail; "best practice" cannot fail and therefore settles
    nothing.
*   Give the acceptance clause a decision maker and a deadline. Acceptance by
    silence is not a safeguard, because silence is what happens when nobody
    was ever given the obligation to decide.

Alignment:
The statement of work should be aligned and consistent with:
*   The procurement strategy, which decides what is bought and on what terms
*   The requirements documentation, so the scope described here is the scope
    the project is managing
*   The change request and change log, because the change route written here
    is the one those records follow

Section Instructions:
*   Scope and Deliverables: what will be delivered, by when, to what standard,
    and how acceptance will be decided, with the exclusions and the authority
    that agreed it stated rather than implied.
*   Terms and Governance: who is accountable on each side, what both parties
    are assuming, and how a change gets in - the parts that decide whether
    the document governs the period of performance or is read once at
    signature.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Project_Name}} - {{Project_ID}}</h2>
<h1 dir="ltr" align="center">STATEMENT OF WORK</h1>

| **Date Prepared:** {{Current_Date}} | **Project Manager:** {{Project_Manager_Name}} | **Prepared By:** {{Prepared_By}} |
| :--- | :--- | :--- |

---

## Scope and Deliverables

### Purpose and Authority

[ Add details... ]

---

### Scope of Work

[ Add details... ]

---

### Period of Performance

[ Add details... ]

---

### Deliverables and Schedule

[ Add details... ]

---

### Applicable Standards

[ Add details... ]

---

### Acceptance Criteria

[ Add details... ]

---

## Terms and Governance

### Roles and Responsibilities

[ Add details... ]

---

### Assumptions and Dependencies

[ Add details... ]

---

### Change Control

[ Add details... ]

---

### Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Procurement Manager** | {{Procurement_Manager_Name}} | _______________________ | [ .... - .... - .... ] |
| **Technical Lead / Project Manager** | {{Project_Manager_Name}} | _______________________ | [ .... - .... - .... ] |
| **Vendor / Contractor Representative** | {{Vendor_Representative_Name}} | _______________________ | [ .... - .... - .... ] |
---

<div dir="ltr" align="right" style="margin-top: 20px; font-size: 12px; color: #7f8c8d;">
  <span>Electronic Audit Trail: Hash SHA256: {{Audit_Trail_SHA256_Hash}}</span> <br>
  <strong>Template:</strong> STATEMENT OF WORK | <strong>Ref:</strong> PMO-04.09.04 <br>
  <i>Generated on: {{Current_Timestamp}}, by <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">Tasleemat</a></i>
</div>

User Guide & Practitioner Instructions

Tasleemat Forms Guide

Project Artifact: Statement of Work

Document Reference: PMO-04.09.04

This document provides a comprehensive, professional reference to understand the purpose and effective usage of the Statement of Work in alignment with the Tasleemat framework.

1. What?

Two sections. The first is what will be delivered: the purpose and the authority behind it, the scope, the period of performance, the deliverables against their dates, the standards they must satisfy, and the criteria by which the buyer will accept each one. The second is what makes those terms hold: who is accountable on each side, what both parties are assuming and depending on, and the route by which a change enters the document.

2. Why?

Because a document that describes deliverables without naming the authority that approved them and the mechanism by which they can be changed is not a contract document, it is a proposal in the wrong folder. Everything difficult about a statement of work happens after it is signed: the scope is read more widely than it was written, an assumption turns out to be false, and somebody needs extra work. The authority clause settles who agreed what, and the change route decides whether that extra work becomes a conversation or a dispute. Omitting them does not simplify the project; it defers both arguments to the moment they are least welcome.

3. When?

Once, before the work begins, and then revised only through the change route the document itself defines. It is not a living record of what is happening, which is what the issue and change logs are for; a statement of work edited in place stops being the thing both parties agreed to, and the point of holding a copy is that neither party can quietly move it. Read again at closeout, where the question is not how the work went but whether what was delivered is what was written here.

4. Who?

Owned by the procurement manager, who holds the contract and is the only party with standing to commit the buyer, with the project manager supplying the schedule and requirements context so the scope described is the scope the project is managing. The client representative signs because acceptance criteria bind the customer, not the supplier, and a criterion no customer has agreed to is a criterion the customer can decline to apply when it becomes inconvenient.

Tailoring Tips

Write what is excluded. An omission reads as an inclusion, and almost every argument about scope begins with something nobody said.
Name the standard rather than describing it. A named standard can be tested and can fail; a description of good practice cannot fail and therefore settles nothing.
Give the acceptance clause a decision maker and a deadline. Acceptance by silence is not a safeguard, because silence is exactly what happens when nobody was given the obligation to decide.
Name an approver for the change route. A change process described without an approver is not a control; the first change becomes a conversation and the second becomes the dispute.

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

Mandatory:
- Project Scope Statement (PMO-04.02.05)
- Cost Baseline (PMO-04.04.04)
- Project Schedule (PMO-04.03.08)
Optional / Contextual:
- Risk Register (PMO-04.08.02)
- Resource Requirements (PMO-04.06.02)

2. Downstream Dependents

Mandatory:
- Statement of Work / SOW (PMO-04.09.04)
- RFP (PMO-04.09.05)
- Contract Closure Report (PMO-07.02)
Optional / Contextual:
- Vendor Performance Scorecard (PMO-06.09)
- Contractor Status Report (PMO-06.03)

5. How?

To accurately complete the Statement of Work, populate the following sections based on the project context (ensuring reference to parameters.md for the general project variables):

Purpose and Authority: What this statement of work is authorised to do, and by whom. The authority clause is the one that settles a dispute about whether something was in scope: it names the instrument that created the obligation - the contract, the charter, the minute that approved it - so that a later reader can tell an agreed obligation from a good suggestion.
Scope of Work: The work to be performed, described so that both parties would recognise the same work from this description alone. Boundaries are part of the description: what is explicitly excluded matters as much as what is included, because an omission read as an inclusion is the most common way a statement of work is argued about after the fact.
Period of Performance: The start and end dates, with any phases or extensions written in rather than left to a separate schedule. The end date is the one that carries the obligation, because it determines when acceptance becomes due and therefore when payment may fall due with it.
Deliverables and Schedule: What will be handed over and by when, milestone by milestone rather than as a single lump. A deliverable without a date attached to it is a topic rather than an obligation, and it is the absence of dates that lets a period of performance run past its end without anybody having to decide anything.
Applicable Standards: The technical, quality and regulatory requirements the deliverables must satisfy, named so that conformance can be tested rather than asserted. "Best practice" is not a standard, because there is no test that fails it; a named standard either passes or does not.
Acceptance Criteria: How the buyer will decide that each deliverable is accepted, who decides it, and how long they have to decide. An acceptance clause that omits the rejection route accepts the deliverable by default on silence, which removes the only leverage a buyer has over a supplier who has already been paid to try.
Roles and Responsibilities: Who is accountable for each part of the work on each side, named by role rather than by person so the document survives a change of staff. The line that matters is the boundary of authority: who may approve a delivery, who may commit additional effort, and who may not do either without going back to the contract.
Assumptions and Dependencies: What both parties are taking to be true, and what the work depends on that is not under the supplier's control - access, data, decisions from third parties. This is the section that determines who carries the schedule when an assumption turns out to be false, and leaving it out converts a dependency problem into a dispute.
Change Control: How a change to the scope, the deliverables or the dates gets into the statement of work, who approves it, and what happens to the price and the dates when it does. A change route that is described but not named is not a control: without an approver and a form, the first change of scope becomes a conversation, and the second one becomes the dispute.

Associated Templates

6. Reference Example

A fully completed, gold-standard reference example illustrating this artifact in practice is available:

📖 Completed Example: 04_09_04_Statement_of_Work_SOW_Example.md

LLM Generation Prompt & Agent Instructions

Statement of Work - LLM Generation Prompt

SYSTEM INSTRUCTIONS: This document is the detailed instruction set for generating the Statement of Work. When asked to populate the template, follow the guidance for each section below to produce the requested content. Refer to parameters.md for the general project variables.

Context and Definition: A record of what will be delivered, by when, to what standard, how acceptance will be decided, and who may change it and how. The difference from a proposal is not tone but authority: a proposal describes work somebody offered to do, a statement of work describes work somebody agreed to do, names the instrument that agreed it, and gives both parties a route to change it without anybody having to break the contract.

Alignment & Dependencies: * Pre-requisites (Inputs): * Mandatory: Project Scope Statement (PMO-04.02.05), Cost Baseline (PMO-04.04.04), Project Schedule (PMO-04.03.08) * Optional: Risk Register (PMO-04.08.02), Resource Requirements (PMO-04.06.02) * Downstream Dependents: * Mandatory: Statement of Work / SOW (PMO-04.09.04), RFP (PMO-04.09.05), Contract Closure Report (PMO-07.02) * Optional: Vendor Performance Scorecard (PMO-06.09), Contractor Status Report (PMO-06.03)

Scope and Deliverables

Purpose and Authority

Instructions: What this statement of work is authorised to do, and by whom. The authority clause is the one that settles a dispute about whether something was in scope: it names the instrument that created the obligation - the contract, the charter, the minute that approved it - so that a later reader can tell an agreed obligation from a good suggestion.