Statement of Work

Abstract

The Statement of Work (SoW) is a formal document that specifies the scope of customer engagement. It serves as a valuable tool for project managers seeking to define all aspects of work management associated with their project, enabling them to establish a baseline scope, limit "scope creep," and set appropriate customer expectations. Statement of Work documents can be developed and used in various ways, however, in this Wiki article the focus will be on the application of SoW documents when dealing with hardware and software systems. This article provides a comprehensive review of the areas that a SoW document typically covers for a project, including introduction, solution definition, project deliverables, project organization and project framework. The content of the SoW document varies based on the complexity level of the project, which can be categorized as foundation (basic), advanced (medium), or integrated (high) levels. Projects with higher complexity require more detailed documentation of work management aspects. Finally, this article offers a practical example of the SoW document's use in a healthcare company.

Purpose and importance of the SoW document

A Guide to the Project Management Body of Knowledge (PMBOK Guide) defines a Statement of Work as:

"A narrative description of products or services to be supplied under the contract.”

The definition, as written, can be interpreted to mean only those products and services to be provided to the customer, however, in actuality, it should also encompass the needs and requirements of the contractor to properly perform the delivery of the products and services (facility requirements, security access, and so forth). To ensure clarity, the definition may be expanded upon to read:

“A narrative description of the products and services to be supplied to a client, as well as a description of the contractor's needs and requirements to properly perform the delivery of such products and services under the contract."

The Statement of Work (SoW) is a formal document that specifies the scope of a particular customer engagement. It serves the purpose of being a valuable tool for project managers seeking to define all aspects of work management associated with their projects. The statement of work (SoW) document defines the scope of the project for the Project Manager during the presales phase. A SoW is mainly required to develop and use when a system with both an installation obligation and where a project manager is required. The SoW is a translation of the customer's needs to a comprehensive solution definition for that customer. It can be stated that the SoW document is an important tool in project management for various reasons which will now be elaborated on. The SoW document helps define the scope of work as it serves as a formal agreement between the project manager, the project team, and the customer. Furthermore, the document helps set clear expectations and establish a common understanding of the project deliverables. The SoW helps prevent scope creep which is a common problem in project management, where the project's scope expands beyond its original definition, resulting in delays, cost overruns, and lower-quality work. The SoW document helps to prevent scope creep by clearly defining the project's boundaries and limiting changes to the scope of work. It facilitates communication as it serves as a communication tool between the project team, project manager, and the customer to ensure that each party is up to date on the progress of the project. Lastly and most importantly it provides a solid foundation for project planning and management allowing the project team to develop a detailed project plan that is aligned with the deliverables, timeline, and scope of the project. Overall the SoW document will help contribute to completing projects successfully with minimal disruptions and/or delays.

Key elements of the SoW document

There are many ways to build up your SoW document, but some of the main key elements that the document can consist of are the following: project summary, governance, deliverables, acceptance and success criteria, constraints, roles, and responsibilities (RACI), timeframes (milestone planning), and physical location of the workplace. In this section, there will be an elaboration of the different key elements.

Introduction

Entails an executive summary and a schedule. The Project Summary and Purpose section is the creation of a brief introduction/summary, purpose statement, and scope of work for your project. In this section, you can dive further into the purpose of your project and the definition of the project scope.

Solution Definition

project objectives, project approach (milestone planning), system testing, customer acceptance (Acceptance and success criteria), physical location of the workplace, and transition to support.

Project Deliverables

In this section all the deliverables of the project are detailed. A project deliverable refers to all outputs associated with the project, whether tangible or intangible and must be completed to finish the project[1]. The key deliverables of the project play a crucial role in completing projects on time, on budget, and with minimal disruption and friction. The project deliverables need to be agreed upon early during the planning stage to properly set customer expectations and allocate resources, and documented within a governing project charter so they can be referenced throughout the duration of the project [2]. The project deliverables can be divided into internal and external deliverables, where the internal deliverables refer to the ones you submit to your own project team members, this could for example be a progress report or a project budget report. The external deliverables are the ones submitted to stakeholders outside of your company, e.g., customers, and can for example be the specifications of the final design or product. For the SoW document, there are only documented external deliverables as this is a document that is developed with the customer. The internal deliverables have no such value to the customers in this case.

Project Organization

Roles and responsibilities (RACI), work roles and responsibilities

Project Framework

Governance Constraints

Project complexity level impact on SoW

When writing a SoW document, the complexity level can have a significant impact on the structure of the document. Therefore the goal is to create a comprehensive SoW document with a focus on tailoring the content to the complexity level of the project. One of the most important areas that need to be filled out first is the scope of work, and the complexity of the project affects what needs to be defined here. The higher the complexity, the more interdependent tasks which means that the scope of work needs to be as detailed as possible. Another key element affected by the complexity level is milestone (timeline) planning. Naturally, a project with higher complexity will have a longer timeline than a foundation-level project. The number of deliverables will also increase with complexity meaning that they may need to be broken into smaller deliverables to ensure they are delivered within the deadline. Resources are required to complete a project and with a project that has high complexity, it is entailed the project may require resources that have specialized skills or equipment. Lastly, another important aspect to consider when increasing the complexity is the number of stakeholders that are involved in the project, which needs to be reflected in the SoW document.

Insert image of the "pyramid" showing the three different complexity levels to a project

Strategies for preventing scope screep

Bullet points of the areas the author wants to dive deeper into:

• What is scope creep?
• Elaborating when a project is particularly vulnerable to the scope creep.
• Strategies to prevent/eliminating scope creep with the help of the SoW document.

Example of successful use of the SoW in the healthcare industry

As the author works in a healthcare company where the SoW document is used, they would like to give an example of what a SoW looks like in this context

• Scope definition at the healthcare company - what did it involve?
• Stakeholder involvement - which parties were involved?
• Monitoring of the project with the help of SoW document - how was it done?
• Detailing how the SoW contributed to a succesful project execution.