Statement of Work Done

Standard Operating Procedure: Statement of Work Done (SOWD) Generation

1. Document Control Block

• Document ID: TR-OPS-SOWD-GEN-001
• Effective Date: 2023-10-27
• Version: 1.0
• Review Cadence: Annual

2. Executive Summary & Scope

This Standard Operating Procedure (SOP) defines the systematic process for generating an accurate, comprehensive, and auditable Statement of Work Done (SOWD) at Template Registry. The SOWD serves as the official record of completed work against a defined Statement of Work (SOW) or project agreement, facilitating client verification, project closure, and financial reconciliation.

Purpose: To standardize the creation, review, approval, and distribution of SOWDs, ensuring transparency, accountability, and the verifiable closure of project phases or entire projects.

Objectives:

• Ensure all project deliverables are accurately documented as completed.
• Provide a clear, defensible record for client billing and project reconciliation.
• Facilitate efficient project closure and knowledge transfer.
• Mitigate disputes related to work completion and scope.

Scope: This SOP applies to all Template Registry projects and service engagements requiring formal documentation of work completion. It encompasses the entire lifecycle of SOWD generation, from data collection to final archival and financial handoff. Exclusions: This SOP does not cover the initial Statement of Work (SOW) drafting, project planning, or change order management, except where their outputs are inputs to the SOWD process.

3. Prerequisites & Required Tools

3.1. Prerequisites

• Approved Statement of Work (SOW) or contractual agreement defining project scope, deliverables, and timelines.
• Completed project phases or entire project, verified against the SOW.
• All project deliverables are finalized and accepted internally.
• Access to all relevant project documentation, including task logs, time entries, and communication records.

3.2. Required Tools & Systems

• Project Management Software (PMS): Jira, Asana, Monday.com (for task tracking, progress updates, deliverable status).
• Time Tracking System (TTS): Harvest, Clockify, Tempo (for accurate effort logging).
• Documentation Repository: Confluence, SharePoint, Google Drive (for project artifacts, deliverable storage).
• Communication Platform: Slack, Microsoft Teams, Email (for stakeholder communication and approval trails).
• Financial Management System (FMS): QuickBooks, SAP, NetSuite (for billing integration).
• Template Registry SOWD Template: Standardized document template for consistent reporting.
• PDF Conversion Software: Adobe Acrobat Pro, built-in system features.

3.3. Compliance Standards

• Internal project governance policies.
• Client contractual terms and conditions regarding project reporting and sign-off.
• Data privacy regulations (e.g., GDPR, CCPA) if client data is included.

4. Roles & Responsibilities (RACI Matrix)

5. Step-by-Step Procedure

Phase 1: Initiation of SOWD Generation

• 1.1. Trigger SOWD Process:
  • PM identifies completion of a defined project phase or entire project as per the SOW schedule.
  • PM confirms all associated tasks in PMS are marked "Completed" and all primary deliverables are submitted.

Phase 2: Data Collection & Aggregation

• 2.1. Gather Project Data:

  • PM extracts comprehensive list of completed deliverables from PMS, cross-referencing against original SOW.
  • PM compiles total hours logged by the team from TTS, categorized by task or deliverable where possible.
  • PM collects relevant project artifacts, screenshots, test results, and client communications (e.g., acceptance emails) from Documentation Repository.
  • PM consolidates any approved change requests (CRs) that impacted scope, deliverables, or timelines.

• 2.2. Verify Data Accuracy (PM with TL/QA):

  • TL reviews technical deliverable completion statuses and provides confirmation of functional acceptance.
  • QA Specialist verifies that all quality checks have been performed and passed for key deliverables.
  • PM cross-references reported hours with actual work performed, flagging any significant discrepancies for investigation.

Phase 3: Drafting the SOWD

• 3.1. Populate SOWD Template:
  • PM utilizes the official Template Registry SOWD Template.
  • PM inputs Project Name, Client Name, SOW ID, and relevant dates (start, end, SOWD creation).
  • PM lists all completed deliverables, matching them to the original SOW line items. Include dates of completion/submission.
  • PM provides a concise summary of work performed for each major deliverable or project phase.
  • PM documents total effort expended (e.g., person-hours) and compares against estimated effort from the original SOW (if applicable and contractually relevant).
  • PM includes any accepted Change Requests (CRs) that modified the original SOW, detailing their impact on deliverables or timelines.
  • PM attaches or references supporting documentation (e.g., links to final deliverables in Documentation Repository, key acceptance emails).
  • PM drafts a clear statement requesting client review and formal approval.

Phase 4: Internal Review & Validation

• 4.1. Technical Review (TL):

  • PM submits SOWD draft to TL for technical accuracy and completeness.
  • TL verifies all technical aspects of the SOWD are correct, and completed work aligns with technical specifications.
  • TL provides feedback or approval to PM within agreed SLA (e.g., 2 business days).

• 4.2. Quality Assurance Review (QA Specialist):

  • PM submits SOWD draft (post-TL review) to QA Specialist.
  • QA Specialist reviews SOWD against internal quality standards, ensuring all deliverables meet acceptance criteria and are accurately represented.
  • QA Specialist provides feedback or approval to PM within agreed SLA (e.g., 2 business days).

• 4.3. PM Final Internal Review:

  • PM incorporates feedback from TL and QA Specialist.
  • PM performs a final self-review for consistency, grammar, spelling, and adherence to contractual terms.
  • PM ensures all required internal signatures/approvals are obtained if applicable (e.g., PM's direct manager for high-value projects).

Phase 5: Client Review & Approval

• 5.1. SOWD Submission to Client:

  • PM converts the final internal SOWD to a non-editable PDF format.
  • PM emails the SOWD to the Client Representative, clearly stating the purpose and requesting formal review and approval by a specified deadline (e.g., 5 business days).
  • PM ensures the communication method (email, client portal) aligns with contractual requirements for formal notices.

• 5.2. Client Feedback & Revisions:

  • If client provides feedback, PM logs all comments and assesses their validity.
  • PM engages TL/QA as needed to address client queries or disputes.
  • PM makes necessary revisions to the SOWD, documenting changes.
  • PM resubmits revised SOWD to client for approval, highlighting changes made. (Repeat until approved).

• 5.3. Client Formal Approval:

  • PM obtains explicit written approval from the Client Representative (e.g., signed PDF, email confirmation stating "approved").
  • PM ensures the approval matches contractual requirements for project sign-off.

Phase 6: Finalization & Archival

• 6.1. Final SOWD Document Preparation:

  • PM ensures the approved SOWD includes all required signatures (internal and external).
  • PM finalizes the SOWD as a locked PDF document.

• 6.2. Archival:

  • PM uploads the final, approved SOWD (PDF) to the designated Documentation Repository.
  • PM verifies the SOWD is stored in the correct project folder with appropriate naming conventions (e.g., [ProjectName]_SOWD_[YYYYMMDD]_vX.X.pdf).
  • PM ensures all supporting documentation (internal review comments, client approval email) are linked or archived alongside the SOWD.

Phase 7: Financial Handoff

• 7.1. Notify Finance:

  • PM informs the Finance Department that the SOWD is approved and archived, and that billing can proceed.
  • PM provides Finance with a direct link to the approved SOWD in the Documentation Repository.
  • PM ensures all relevant billing details (e.g., contract value, payment terms, phase completion) are communicated.

• 7.2. Invoice Generation (Finance):

  • Finance Department initiates invoice generation based on the approved SOWD and contractual terms.
  • Finance Department cross-references SOWD with internal financial records.

6. Quality Assurance & Verification

6.1. Key Metric Thresholds

• Deliverable Completion: 100% of SOW deliverables listed in SOWD must be marked as 'Completed' and verified.
• Effort Variance: Total reported effort (person-hours) should be within +/- 15% of the original SOW estimate, or any variance must be explicitly justified and approved via change control.
• Approval Rate: 100% of required internal and external approvals obtained before final archival.
• Turnaround Time: Client approval within 10 business days of initial submission (configurable per contract).

6.2. Common Pitfalls & Mitigation

• Incomplete Data Collection: Ensure robust PMS/TTS usage and mandatory fields. Regular PM review of data health.
• Discrepancy in Reported Work: Standardize tracking methods. Regular internal syncs between PM, TL, and project team.
• Lack of Client Engagement/Sign-off: Proactive communication from PM. Set clear expectations and deadlines. Escalate non-responsiveness as per client engagement protocol.
• Scope Creep Misreporting: Any work outside original SOW must be documented via formal change requests and explicitly mentioned or excluded in SOWD.
• Version Control Issues: Strict adherence to template and document naming conventions. Use controlled repositories.

6.3. SOWD Audit Checklist

• Is the SOWD linked to an original, approved SOW or contract?
• Does the SOWD utilize the official Template Registry SOWD Template (TR-SOWD-TEMP-vX.X)?
• Are all listed deliverables in the SOWD cross-referenced with PMS entries and marked as complete?
• Is there verifiable proof of deliverable completion (e.g., links to artifacts, test results)?
• Are total effort hours documented and aligned with TTS records?
• Is there documented approval from the Technical Lead?
• Is there documented approval from the Quality Assurance Specialist?
• Is there explicit, written formal approval from the Client Representative?
• Is the final SOWD a non-editable PDF and properly archived in the Documentation Repository?
• Is there a record of communication to the Finance Department for billing initiation?

7. Troubleshooting FAQ

Q1: The client is disputing certain items or hours listed in the SOWD, refusing to approve. A1:

• Action: Immediately schedule a joint meeting with the Client Representative, PM, and TL to review specific disputed items.
• Evidence: Present objective evidence from PMS (task completion, comments), TTS (detailed time logs), and Documentation Repository (screenshots, acceptance emails, communication logs) to support the reported work.
• Resolution: If a genuine discrepancy is identified (e.g., error in reporting, misunderstanding of scope), PM will revise the SOWD with justification. If the client's dispute is unfounded against objective data, PM will politely but firmly reiterate contractual agreements and documented evidence. Escalate to senior management if resolution is not reached within 2 follow-ups.

Q2: The project team failed to log hours or update task statuses consistently in the PMS/TTS, leading to incomplete data for the SOWD. A2:

• Action: PM must conduct a retrospective data reconstruction. Interview team members individually to reconstruct missing time entries and task updates.
• Verification: Cross-reference reconstructed data with available communication logs (e.g., Slack, email) and meeting minutes.
• Mitigation: For future projects, reinforce mandatory daily time logging and task updates. Implement automated reminders and regular PM audits of PMS/TTS data hygiene. Include data accuracy as a team performance metric.

Q3: An internal required approval (e.g., TL or QA) is pending indefinitely, blocking SOWD submission. A3:

• Action: PM must send a direct reminder with a clear, short deadline (e.g., 24-48 hours).
• Escalation: If no response or approval, PM must escalate to the approver's direct manager, providing context of the delay and its impact on project closure and billing.
• Bypass (Exceptional): In extremely rare, critical circumstances and with explicit senior management approval, a temporary bypass might be considered, but full documentation of the bypass and the reason is mandatory. This should be an exception, not a rule.