SOW Template

🎯 Theme: Writing scopes of work that define real deliverables

This page provides a comprehensive Statement of Work template for data strategy development projects, covering all essential sections from problem definition to deliverables, risks, and constraints to ensure clear project boundaries and stakeholder alignment.

The following Statement of Work template can be used when working with a city or partner or client when embarking on a project. The SOW should govern any project work being done so that the confines of the project are defined and ensure that everyone is on the same page around deliverables

Support for Data Strategy Development and Execution

[Client Organisation Name]

Prepared by: [Partner Organisation Name]

Date: [Insert Date]

1. Introduction

This section introduces the context, background, and purpose of the engagement. It should include a short history of the engagement, how the opportunity arose, who the key stakeholders are, and the broader programme the work falls under (if applicable).

What to include checklist:

• Brief background and context for the project.
• How the project was initiated (e.g. meeting, request, opportunity).
• Who the key stakeholders are.
• Which broader programme or initiative it belongs to, if any.

Example:

On [insert date], the [Organisation/Team] met with [Partner Name] to discuss how support could be provided for [describe issue or opportunity]. This conversation was part of [project or programme name], which is funded by [funder, if applicable] and implemented by [implementing partner/organisation]. This document outlines the scope of the first iteration of work based on this engagement.

2. Problem Statement

This section outlines the core problem that this work is responding to. It should clearly explain the existing challenge, how it manifests operationally or in service delivery, and why it matters now. If possible, provide real-world examples or evidence, and explain any previous or existing efforts that are relevant to understanding the current state.

What to include checklist:

• The problem or challenge you are trying to address.
• Why this is important to solve.
• Any existing efforts or context that adds to understanding the problem.

Example:

Currently, [describe how the issue is being handled]. This results in challenges such as [list key challenges]. While there are existing efforts, such as [mention if CRM systems, reports, tools are in place], the current method remains [explain shortcomings]. Because of this, it becomes difficult to [describe impact—track issues, make decisions, provide updates, etc.]. This project aims to address the gap by [outline approach—e.g., prototyping a dashboard to show value].

3. Objectives and Outcomes

This section sets out what this work aims to achieve and why it matters. It describes the intended outcomes (both short- and longer-term), how these contribute to the broader goals of the organisation or programme, and how change will be measured or observed. It is useful to frame this within a light theory of change, even if informal, to explain how the proposed intervention leads to the desired impact.

What to include checklist:

• The primary goals of this scope of work.
• What success looks like (e.g. a prototype, insights, improved workflow).
• Clear deliverables that can be measured or reviewed.

Example:

The primary objective of this work is to support the City in building more responsive and data-informed services by addressing a key operational challenge related to [insert problem]. In the short term, this will be achieved through the development of a prototype dashboard and the introduction of a simple data pipeline that allows municipal staff to more easily see, interpret, and act on data from community reports.

The intended outcome is that staff will be better equipped to prioritise service requests, report on response times, and identify areas where resources need to be allocated more strategically. Over time, this improved access to and use of data is expected to strengthen internal decision-making processes, improve service delivery responsiveness, and build greater trust between government and communities.

This work aligns with the organisation’s broader theory of change, which holds that equipping cities with better data tools, workflows, and capabilities leads to stronger governance, improved services, and ultimately more equitable and resilient cities. By investing in targeted interventions that demonstrate immediate value while building toward long-term systems change, the project contributes to the wider objective of enabling cities to become more agile, transparent, and accountable to residents.

Where possible, the project team will document early signs of progress and feedback from users to inform future iterations. This includes capturing usage of the dashboard, examples of decisions that have been influenced by the data, and reflections from staff on how the tools have changed their day-to-day work.

4. Data Processes

This section describes the data workflow and technical components of the project. It includes a description of the existing process (current state or “as is”), the proposed intervention (future state or “to be”), and a description of how data will be collected, transformed, and used. Diagrams may be used to support this explanation. Any manual or temporary workarounds should be noted.

What to include checklist:

• Summary of the existing (as-is) data process.
• Proposed (to-be) data workflow, even if temporary.
• Include diagrams if helpful.
• Describe roles, tools, and how data will flow between steps.

Example:

Based on the initial engagement, the current data pipeline was mapped and is illustrated in the diagram below (Figure x). This represents the existing method of capturing and handling the data and will need to be reviewed and validated by [partner name].

To move towards a more structured process, a temporary workflow has been proposed (Figure y). This process involves manually transforming the existing data into a new data schema that can feed into a concept dashboard. The key steps to actualise this are:

• Designing a simplified data schema aligned with dashboard requirements.
• Capturing data from one existing report manually to populate the schema.
• Developing a Power BI dashboard prototype to visualise the information in a useful and accessible way.

These manual steps are intended as a stop-gap measure to showcase the value of more structured data systems and provide the foundation for future iterations of work.

5. Milestones

This section outlines the key deliverables and deadlines of the engagement in a tabular format. Each milestone should have an associated date and status to track progress. This helps align expectations and creates accountability.

What to include checklist:

• Key milestones with target dates and status.
• Consider using a table format.
• Helps track progress and determine completion.

Example Format:

6. Project Team and Resourcing

This section outlines who is involved in delivering the project and what their roles are. It is useful to include a simple table or list of names, roles, and specific contributions to the project.

What to include checklist:

• Team members and their roles.
• Partners/stakeholders involved.
• Resource contributions (time, skills, tech).

Example:

The table below outlines the project team who will be responsible for completing this work.

7. Risks

This section identifies potential risks that could affect the success of the project, their impact, likelihood, and the mitigation strategies that will be used. Each risk should have a clear owner and mitigation plan.

What to include checklist:

• Identify risks that could affect the success of the project.
• Assess likelihood and impact.
• Outline mitigation strategies and assign ownership.

Example:

A few risks have been identified that may impact delivery timelines and outcomes. These include scope creep, due to the need for a more comprehensive system beyond the prototype. To manage this, the team will maintain regular check-ins with the partner to ensure expectations remain aligned. Another risk is the availability of the partner to provide timely feedback, which will be mitigated through early scheduling and regular reminders. A third risk is the duplication of efforts if similar dashboards exist elsewhere in the city—this has been noted and will be explored further in future phases of the work.

8. Out of Scope

This section clearly defines what will not be covered under this project. It is especially useful in managing expectations and ensuring the work remains focused on its stated goals.

What to include checklist:

• Explicitly state what this scope does not include.
• Helps manage expectations and avoid misunderstanding.

Example:

This scope of work is limited to the development of a prototype dashboard using a limited dataset. It does not include the development of a full data pipeline, the manual entry of data from all community reports, or the integration of the dashboard into municipal systems. Future work will explore how these components can be addressed through subsequent iterations

9. Project Constraints

This section lists any constraints that may affect project delivery—such as deadlines, budget limitations, data quality issues, regulatory conditions, or equipment/software availability. Where applicable, disclaimers can be included.

What to include checklist:

• Project Dates: Start, end, and key deadlines.
• Budget: Funding and cost breakdown.
• Quality Limits: Data accuracy, tool constraints.
• Tools & Access: Licences, hardware, etc.
• Legal/Regulatory: Any disclaimers or responsibilities.

Example:

The project is expected to begin on [start date] and conclude on [end date]. The timeline is fixed in order to align with programme deadlines and to ensure the work feeds into upcoming planning cycles. The total project budget is $[amount], covered under [programme name]. As the data being used is manually captured and based on unstructured reports, the dashboard will not reflect complete or fully accurate service delivery performance but will instead serve as a concept tool. Access to Power BI for municipal staff will also need to be confirmed for review and future adoption. All outputs will carry the following disclaimer: [Insert disclaimer].

10. Signatures

Client Representative

Name:

Title:

Signature:

Date:

Firm Representative

Name:

Title:

Signature:

Date:

🧩 Optional Sections

You can add the below sections depending on complexity of your project:

• Dependencies (e.g. need access to certain files or systems).
• Assumptions (e.g. stakeholders will provide feedback within 3 days).
• Glossary (if the document uses technical terms).