Statement of Work

Revision as of 22:05, 9 April 2023

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.

The Statement of Work document

Purpose and definition

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.

Importance

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:

• Introduction
• Solution Definition
• Project Deliverables
• Project Organization
• Project Framework
• Review and Signature Page.

In this section, there will be an elaboration of the different key elements.

Introduction

Having an introduction section in the SoW document is important because it sets the stage for the entire document and provides context for the reader throughout the document. The Introduction section typically covers the following areas; an executive summary, purpose statement, brief schedule, and equipment installation address of the project. In this section, there is an opportunity to explain what type of work that is being executed and general information about the project. To write about the purpose of the project, a good question to start answering is "Why is the project being initiated and what is the purpose of this project?". By answering this question in the purpose statement, the Project Manager can ensure that all stakeholders have a clear understanding of what the project entails. The necessary tasks and required equipment (hardware and/or software) of the project can also be documented in the scope of work. The Project Manager also gets to briefly describe the processes they will utilize to execute the project, detailing the expected outcomes and general steps needed to move on. The brief project schedule contains the following information; project start and end dates, key milestone dates, deliverable due dates, and the overall work schedule specifying hours spent on project-related activities. Having a brief schedule in the introduction section of the SOW document can help stakeholders to understand the project timeline and dependencies, which can be important for managing resources and ensuring that the project stays on track. It can also help to identify any potential scheduling conflicts or delays early on in the project, allowing for proactive mitigation strategies to be put in place. Additionally, the introduction can help to establish credibility and build trust with the reader, which can be important for securing their buy-in and support for the project. Overall, a well-crafted introduction is essential for laying the foundation for a successful project. Lastly, the introduction should include the equipment installation address allowing the stakeholders to have an understanding of where the equipment will be installed, which is critical to ensure that the installation becomes successful.

Solution Definition

The Solution Definition section is rather comprehensive and can contain the following subsections; Project Objectives, Project Planning Approach, System Testing, Customer Acceptance and Success Criteria, and Transition to Support.

Project Objectives

Starting with addressing the different subsections one by one, the Project Objectives are defined as:

"Something toward which work is to be directed, a strategic position to be attained, a purpose to be achieved, a result to be obtained, a product to be produced, or a service to be performed" (ref: PMBOK)

This is a subsection that contains a description of the high-level objectives of the project. For example, a brief description of the systems being implemented should be provided along with an overview of the workflow with linkages to the benefits that the customer is expecting to achieve from this project. (ref: Internal SoW) To write down some ideal project objectives in an effective manner, the project manager can use the SMART methodology which stands for:

• Specific
• Measurable
• Achievable
• Realistic
• Time-bound

By using the SMART methodology the project manager ensures clear communication and alignment, clarity toward project success, a clear roadmap and finish line, and trackable metrics ^[1].

Project Planning Approach

The Project Planning Approach is the process of deciding what the project's objectives are, agreeing on who needs to be involved, determining what needs to be done to deliver the objectives, and what the time and costs will be of doing so (ref: Credit Scoring, Response Modelling and Insurance Rating — 2010, pp. 30-65, Finlay Steven). There are a variety of approaches to project planning, namely:

• Milestone Planning: is focused on milestones instead of activities and is goal-directed and results-oriented [1].
• Agile Planning: this is about understanding how long it takes to perform specific tasks and executing an overall project by breaking it down into sprints. Agile planning is done step-by-step and progressively and allows for changes throughout the project relying on regular feedback from the customer [2].
• Waterfall Planning: is a sequential project management methodology divided into distinct phases with each phase beginning after the previous phase is completed [3].
• Critical Path Method (CPM) Planning: this is a technique that allows the project manager to identify tasks that are necessary for project completion. The critical path in project management is the longest sequence of activities that must be finished on time to complete the entire project ([4].
• Gantt Chart planning: allows project, program, and portfolio managers to easily map out project plans by organizing project tasks on a visual timeline ([5].

There are several approaches to do Project Planning, however, the above-mentioned planning approaches are some of the most used.

Systems Testing

In this subsection, all the details relating to the systems testing will be noted down in the SoW document. According to the PMBOK Guide:

"Testing is an organized and constructed investigation conducted to provide objective information about the quality of the product or service under test in accordance with the project requirements."

The purpose of this section is to write down all the details regarding testing the system in cooperation with the relevant stakeholders/customers. The intent of testing is to find errors, defects, or bugs in the product/service provided (ref: PMBOK). By including systems testing as a section in the SoW, the project manager can help establish the expectations and requirements for testing which ultimately ensures that the testing is comprehensive and meets the need of the stakeholders.

Customer Acceptance and Success Criteria

This part of the SoW states that before the customer begins using the installed system, they must sign a document indicating customer acceptance of the system. The purpose of this document is to agree that the system has been installed according to specifications and is ready for clinical use. However, customer acceptance is obviously based on some success criteria. These success criteria are noted down in collaboration with the project manager and customer, and the aforementioned document can only be signed once the success criteria are fulfilled.

Transition to Support

Lastly, this subsection states that after the system is installed, a Transition to Support meeting will be facilitated. During this meeting, the following will happen:

• Educate the end-users on how to obtain support on the system
• Review the warranty and support agreement, etc.
• Review any open issues and identify an owner of these
• Review the project deliverables and identify any remaining deliverables not yet delivered

The "transition to support" section is an important part of a Statement of Work (SoW) because it outlines the process and procedures for transferring the responsibility of a project from the project team to the support team. This transition is crucial because it ensures that the project's objectives are met and that the end product is successfully delivered to the customer.

Project Deliverables

The PMBOK Guide defines a deliverable as:

"Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project." (ref: PMBOK)

In this section all the deliverables of the project are detailed. As the statement above was defined, project deliverable refers to all outputs associated with the project, whether tangible or intangible and must be completed to finish the project [6]. 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 [7]. 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.

The figure above shows an example of how the Project Manager can create a table with all deliverables of the project listed. The first column is a description of the deliverable whereas the second column is the completion criteria of the given deliverable.

Project Organization

The Project Organization is a section describing the work roles and responsibilities within the organization. It is a good idea to include this section in any SoW as this helps give the stakeholders a clear understanding of the organizational structure and responsibilities of the team. This can for example be done by creating a Responsibility Assignment Matrix (RAM) and incorporating a RACI structure. A RACI structure refers to Responsible, Accountable, Consulted, and Informed and can be incorporated into the RAM. This will help clarify roles and responsibilities, ensure accountability, and facilitate communication [8].

As seen in the above figure, the different roles have each their responsibility areas.

Project Framework

The Project Framework section is to outline the framework that the project manager and customer agree to follow to produce successful project outcomes. This can for example be the listing of some project assumptions, customer responsibilities, and limitations. Within the project framework, it is important to also mention the governance framework.

Governance Framework

The Governance Framework refers to the framework within which authority is exercised in organizations. This framework includes but is not limited to:

• Rules
• Policies
• Procedures
• Norms
• Relationships
• Systems, and
• Processes

The governance framework influences how the objectives of the organization are set and achieved, how risks are monitored and assessed, and finally, how performance is optimized. The governance part in the SoW is especially important because it ensures compliance with regulations, policies, and standards and it mitigates risks by defining risk management processes and procedures.

Review and Signature Page

Lastly and most importantly, the SoW should end with a "Review and Signature Page". The signature page is important due to the reason that serves as a form of evidence of both parties has reviewed and agreed to the terms and conditions outlined in the SoW. The "Review and signature" page provides a formal agreement between the project team and the client. This agreement confirms that both parties have reviewed and agreed to the terms and conditions outlined in the SoW, and establishes accountability and legal protection for both parties.

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

Scope Creep and its elimination strategy

One of the main reasons to develop a SoW document is to prevent scope creep. In this section, there will be an elaboration on the definition of scope creep, what project vulnerability is and then merging those two together to elaborate on how scope creep can be eliminated using the SoW document.

Scope Creep definition

The definition of Scope Creep is the following:

"Scope creep is when a project’s requirements and deliverables stretch beyond the initial vision. In project management, scope creep is one of the leading causes of failure. It occurs when new requests flow in that involve additional revisions, remakes, re-designs, and additional requirements. "^[2].

So, what actually causes scope creep? Scope creep is the phenomenon that takes place when projects overstep their initial goals, more and more tasks keep getting piled on until the deadline is missed and everyone loses steam. There are several various and avoidable causes of scope creep, e.g., lack of planning, lack of communication, too many revisions, and poorly defined project scope.

Another question to ask is when can you expect scope creep? Scope creep can occur at any time during a project, but, some stages of the project are more vulnerable to being affected. This could for example be:

• During the project's initial planning phase
• When the client asks for more revisions and additions that take a long time
• Once a deadline is missed
• When someone is left out of the planning process and comes back later to ask for changes
• When there is a lack of clarity around project deliverables

These are just a couple of examples of when scope creep can occur. The following section will address how to eliminate scope creep with the help of the SoW document.

Eliminating Scope Creep by using SoW

As mentioned in the previous section, a project is more vulnerable in its initiating phases. It is stated that in order to prevent scope creep from happening, the following actions are some examples of what can be done:

• Gain alignment with your team and stakeholders
• Define the scope early on
• Plan every step

One of the best strategies to prevent scope creep is to develop a SoW document. The SoW document will help prevent scope creep by:

• Defining the project scope early: the SoW document is developed in the initiating process step of a project, and as mentioned earlier this is where the project is most vulnerable to scope creep. By defining the project scope early on in the SoW, there is a smaller risk of experiencing scope creep.
• Involve all stakeholders: the SoW document is developed and specified in collaboration with all stakeholders. This will ensure that everyone has a clear understanding of the project scope, timelines, and expectations.
• Provides a baseline for change requests: If changes to the project scope are required, the SoW provides a baseline for evaluating change requests. This can help prevent scope creep by ensuring that changes are evaluated against the original project requirements and objectives.

By including these elements in your SoW, you can help prevent scope creep and ensure that your project stays on track. However, it's important to remember that scope creep can still occur, even with a well-written SoW in place. Therefore, it's important to be vigilant and proactive in managing scope changes throughout the project lifecycle.

References

1. ↑ Martins, J., (2022) SMART Goals https://asana.com/resources/smart-goals (Retrieved 9th April 2023)
2. ↑ Schäferhoff, N., (2021) What is Scope Creep in Project Management? https://elementor.com/blog/scope-creep/?utm_source=google&utm_medium=cpc&utm_campaign=13060922353&utm_term=&gclid=Cj0KCQjwxMmhBhDJARIsANFGOSuPNPEkqAT1hyg7NCy2oP1gmA7mT6-GE3NXhKWdyJC9rL7JbMDkNmQaAsWtEALw_wcB (Retrieved 9th April 2023)