Statement of Work

Revision as of 17:32, 7 May 2023

Abstract

Scope creep is a common challenge faced by project managers which often results in missed deadlines, increased costs, and reduced quality of work. To mitigate scope creep, project managers can use a Statement of Work (SoW) document which outlines the scope of customer engagement in a formal and structured way. This document is, in particular, valuable for managing hardware and software systems projects where scope creep can be problematic. This wiki article will focus on providing a review of the key components of a SoW document such as introduction, solution definition, project deliverables, project organization, and project governance. By establishing a baseline scope and setting appropriate customer expectations, project managers can use the SoW document to limit scope creep and keep their projects on track. The complexity level of the project plays a crucial role in determining the content and level of detail required in the SoW document. This wiki article categorizes projects into foundation (basic), advanced (medium), and integrated (high) complexity levels, and discusses the varying levels of documentation required for each. With the help of using a SoW document effectively, project managers can better manage scope creep, stay on schedule and budget, and deliver high-quality work that meets their customers' needs. Finally, the wiki article will wrap up with a conclusion on how the SoW helps prevent scope creep.

Scope Creep

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, the main causes of its occurrence, and how the SoW document can help eliminate it.

Scope Creep Definition and Causes

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 ^[1]. "

Scope creep is an inevitable challenge within project management that can put some of the even most well-planned projects off track. The phenomenon occurs when new features or work that falls outside the agreed-upon scope are added to a project, leading to missed deadlines, increased costs, and reduced quality of work. 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 phases, when clients ask for more additions, once a deadline is missed, and when there is a lack of clarity around project deliverables. One common cause of scope creep is customers requesting changes that can seem minor or insignificant. To please customers while delivering a high-quality product, project teams may act on these requests without following proper change management procedures, leading to unauthorized scope additions and ultimately scope creep ^[2].

According to the Project Management Institute, the top five reasons why scope creep occurs are:

• Ambiguous or unrefined scope definition
• Lack of any formal scope or requirements for management
• Inconsistent process for collecting product requirements
• Lack of sponsorship and stakeholder involvement
• Project length

To summarize, it is important for project managers to stay alert and actively manage the project scope and monitor the project activities and follow well-established change management procedures to avoid scope creep and deliver projects that meet customer needs. The following section will address how to eliminate scope creep with the help of the SoW document.

How To Eliminate Scope Creep

As mentioned in the previous section, a project can experience scope creep at any time but is the most vulnerable in its initiating phases. The Project Management Institute (PMI) has suggested numerous mitigating actions for each of the causes ^[2], some of which are stated below:

Ambiguous or unrefined scope definition:

• Create a short document containing business needs, project vision, and high-level features in and out of scope
• Define deliverables to form the basis for detailed requirement analysis

Lack of any formal scope or requirements management:

• Include a change management process in the Scope Management Plan
• Review all requirements with stakeholders
• Employ requirements for traceability

Inconsistent process for collecting product requirements:

• Establish and follow requirements processes for scope modeling
• Create scope models early in a project, i.e., Use Case Diagrams, Context Diagrams, etc.

Lack of sponsorship and stakeholder involvement:

• Develop project charters to keep ownership where it belongs
• Use project status reporting that engages sponsors
• Use a tool like RACI (Responsible, Accountable, Consulted, Informed) matrix

Project length:

• Educate sponsors to chunk projects into shorter subprojects
• Decompose projects into smaller subprojects

The SoW document is a helpful tool to prevent scope creep. In the rest of this wiki article, we will delve into the details of the SoW document, exploring what it is, its importance in project management, and tips on how to structure it effectively. By understanding the key elements of the SoW and how to develop a comprehensive, well-structured document, project managers can maximize the benefits of this essential tool and deliver successful projects that meet their customers' needs.

The Statement of Work document

Being appointed as the project manager on a new and large project can be a daunting task, especially if you were not involved in the sales process. Without a clear understanding of the project scope and deliverables, you may find yourself facing significant challenges as the project progresses. As the project manager, it is essential to take the initiative to clarify the scope of work with the sales team and the client to ensure that everyone has a common understanding of what is expected and can work towards a successful project outcome ^[3]. This is where a Statement of Work (SoW) document comes in. The SoW is a formal document that defines the scope of a particular customer engagement and is mainly developed as soon as possible in the proposal process. This section will dive deeper into the definition, purpose, and importance of the SoW document.

Definition and Purpose

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

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

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)^[4]. 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 SoW document serves the purpose of being a valuable tool for project managers seeking to define all aspects of work management associated with their projects. The 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, e.g., providing a solid foundation for the project, serving as a formal agreement between project team and customer, and preventing scope creep. These important factors will be elaborated in this section.

Most importantly, a SoW provides a solid foundation for project planning and management which will allow the project team to develop a detailed project plan that is aligned with the deliverables, timeline, and scope of the project. The document helps set clear expectations and establish a common understanding of the project deliverables.

The SoW document also serves as a formal agreement between the project manager, the project team, and the customer. Furthermore, it facilitates communication as it serves as a communication tool to ensure that each party is up to date on the progress of the project.

Lastly, as mentioned in the earlier section, the SoW helps prevent scope creep ^[5], 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.

To conclude why the SoW document is so important, it is safe to say that the SoW document will help contribute to completing projects successfully with minimal disruptions and/or delays.

Key elements of the SoW document

This section will provide a detailed description of each of these critical components, highlighting their importance in developing a well-structured and effective SoW document. The structure and content of a SoW can vary depending on the project and the needs of the parties involved. While there is no one-size-fits-all approach to creating an effective SoW, there are certain key elements that are commonly included. It is suggested that the SoW document should include the following key elements in the document:

• Introduction
• Solution Definition
• Project Deliverables
• Project Organization
• Project Governance
• Review and Signature Page

In the following section, an in-depth exploration of each of these key elements will be provided, along with recommendations on how to structure and present them effectively.

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. In this section, there is an opportunity to explain what type of work that is being executed and general information about the project. It is recommended that the introduction section typically covers the following areas, executive summary, purpose statement, brief project schedule, and installation address.

Executive Summary

An executive summary is a brief report that highlights the important aspects of a project. The executive summary should provide the reader with the essence of the project status and know how this particular project impacts the organization as a whole ^[6]. 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.

Purpose Statement

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^[7].

Brief Project Schedule

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 ^[7]. 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 identify any potential scheduling conflicts or delays early on in the project, allowing for proactive mitigation strategies to be put in place.

Installation Address

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.

To summarize, the introduction can help to establish credibility and build trust with the reader, which can be important for securing buy-in and support for the project. Overall, a well-crafted introduction is essential for laying the foundation for a successful project.

Solution Definition

The Solution Definition is a detailed description of the solution that will be provided to the customer. This section of a SoW is crucial in providing an understanding of the high-level project objectives, the planning approach, and testing requirements. It is recommended that the solution definition contain the following areas: project objectives, project planning approach, system testing, success criteria, and transition to support. Furthermore, it is recommended that the project manager develops diagrams, e.g., Use Case diagrams, Context diagrams, and Reference Architecture Specification diagrams, to provide the customer and other relevant stakeholders with an in-depth understanding of the solution.

Project Objectives

According to the Project Management Body of Knowledge 6th edition (PMBOK) 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^[4]."

Figure 1: SMART goals^[8]

This section should contain 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.

To write down some ideal project objectives in an effective manner, it is recommended that the project manager can use the SMART methodology. According to the Project Management Institute, SMART stands for ^[9]:

• Specific - the objective is clearly stated
• Measurable - metrics exist or can be created to determine when the objective has been met
• Achievable - the team agrees the objective is realistic
• Relevant - the objective fits the organization's strategic plan and supports the project charter
• Time-bound - a date for achieving the objective is stated

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 ^[10].

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 ^[11]. In this section, the project manager should state which project planning approach they have chosen to work with. 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 ^[12].

• 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 ^[13].

• Waterfall Planning: is a sequential project management methodology divided into distinct phases with each phase beginning after the previous phase is completed ^[14].

• Critical Path Method 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 ^[15].

• Gantt Chart Planning: allows project, program, and portfolio managers to easily map out project plans by organizing project tasks on a visual timeline ^[16].

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 Project Management Body of Knowledge (PMBOK) Guide 6th edition, testing is defined as:

"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 ^[4]."

The purpose of this section is to write down all the details regarding testing the system in cooperation with the relevant stakeholders/customers, i.e., developing a test plan. The intent of testing is to find errors, defects, or bugs in the products and services provided. 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.

According to Bose, S., it is recommended that the systems test plan is developed to contain the following components^[17]:

• Schedule: Details start dates and deadlines for testers to deliver results
• Resource allocation: Details which tester will work on which test
• Environment: Details the test environment's nature, configuration, and availability.
• Defect Management: Details how bugs will be reported, to whom, and what each bug report needs to be accompanied by.
• Risk Management: Details what risks may occur during software/hardware testing and what risks the software itself may suffer if released without sufficient testing.
• Exit Parameters: Details when testing activities must stop.

By including these details in the SoW, the project manager can set clear expectations and requirements for testing, which ultimately leads to a more comprehensive and effective testing process.

Success Criteria

Some of the most important success criteria for a project are cost, scope, and time meaning that if you can deliver a project on time, within budget, and achieve the scope as defined in the project documents, you are most likely to experience a successful project ^[18]. It is recommended for the project manager to create a list of success criteria based on Simplilearn's ten success criteria for projects: scope, schedule, budget, client goals, quality, team goals, deliverables, resource capacity, risk management, and documentation^[19].

Transition to Support

When 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 Project Management Body of Knowledge 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."

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 ^[20].

Figure 2: Example: Table of Deliverables.

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 ^[21].

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.

Figure 2 shows an example of how it is recommended that 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

Figure 3: Example: RACI Chart.^[22]

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. It is recommended that the project manager uses the Responsibility Assignment Matrix (RAM) tool, which is often called a RACI chart. The RACI chart specifies the roles of all stakeholders, both within and outside the company. Furthermore, the RACI chart serves as the baseline of the communications plan by emphasizing who receives information, how frequently, and at what level of detail ^[23].

A RACI structure refers to:

• Responsible
• Accountable
• Consulted
• Informed

An example of a RACI chart can be seen in Figure 3 where the different roles have each their responsibility areas. Overall, the RACI chart serves the purpose to help clarify roles and responsibilities, ensure accountability, and facilitate communication ^[24].

Project Governance

Project governance is an important aspect of a SoW document because it provides direction and definition of procedures, processes, and metrics through the project lifecycle ^[25]. Project governance is defined as:

"Project governance refers to the set of activities and guidelines that determine how a project is planned, executed and managed. You can look at project governance as a framework to help oversee the right course for the project ^[26]."

Some of the roles that are a necessity for establishing and maintaining project governance are: sponsors, steering committee, project management office, and a project manager ^[27].

Project governance should cover the following aspects ^[28].:

• Policies
• Regulations
• Functions
• Processes
• Procedures
• Responsibilities

In order to write the project governance section in the SoW it is recommended that the project manager assesses the level of intensity of the governance framework that they must deploy. This can be done by following these four steps recommended by the Project Management Institute ^[27].:

• Step 1: Define the customer's requirements
• Step 2: Define the proposed solution and success criteria
• Step 3: Use the tool T-Shirt Sizing^[27] to determine the appropriate governance level
• Step 4: Use allocated T-Shirt Sizing

After assessing the project governance level, the project manager can write a section about it in the SoW. 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, closure is needed by having the customer sign off the SoW document ^[7]. 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 have 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 ^[29].

Best Practices

In this section, there will be shared best practices regarding how to use concise language in the SoW and how the project complexity level can impact the SoW document.

Concise language

According to the Project Management Institute (PMI) there are some aspects that need to be considered as best practice when writing the SoW:

Project Complexity Level Impact

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

Limitations

Conclusion

References

1. ↑ 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 (Accessed 9th April 2023)
2. ↑ ^{2.0 2.1} Larson, R. & Larson, E. (2009). Top five causes of scope creep ... and what to do about them. Paper presented at PMI® Global Congress 2009—North America, Orlando, FL. Newtown Square, PA: Project Management Institute. (Accessed 5th May 2023)
3. ↑ Martin, M. G. (1998). Statement of work: the foundation for delivering successful service projects. PM Network, 12(10), 54–57. (Accessed 5th May 2023)
4. ↑ ^{4.0 4.1 4.2 4.3} Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute. (Accessed 5th May 2023)
5. ↑ Albouy L., (2021) What is a Statement Of Work - Full Guide. https://slite.com/learn/statement-of-work (Accessed 6th May 2023)
6. ↑ Kaibni R., (2021) Executive Summary Report. https://www.projectmanagement.com/contentPages/wiki.cfm?ID=354324&thisPageURL=/wikis/354324/Executive-Summary-Report#_=_ (Accessed 6th May 2023)
7. ↑ ^{7.0 7.1 7.2} Landau P., (2023) What Is a Statement of Work? Definition & Examples. https://www.projectmanager.com/blog/statement-work-definition-examples (Accessed 6th May 2023)
8. ↑ Megan M. Flores (2017), The History and Evolution of SMART goals, https://www.achieveit.com/resources/blog/history-evolution-smart-goals/, (Accessed 6th may 2023)
9. ↑ Burek, P. (2006). Developing a complete project scope statement in 2 days. Paper presented at PMI® Global Congress 2006—North America, Seattle, WA. Newtown Square, PA: Project Management Institute. (Retrieved 9th April 2023)
10. ↑ Martins, J., (2022) SMART Goals https://asana.com/resources/smart-goals (Retrieved 9th April 2023)
11. ↑ Steven, F., (2010) Credit Scoring, Response Modelling, and Insurance Rating. (Retrieved 9th April 2023)
12. ↑ Project Management Institute (PMI), (2022) Milestone Different Planning Approaches https://www.pmi.org/learning/library/milestone-different-planning-approach-7635 (Retrieved 9th April 2023)
13. ↑ Arora, S., K., (2023) What is Agile Planning? https://www.knowledgehut.com/blog/agile/what-is-agile-planning-agile-planning-levels (Retrieved 9th April 2023)
14. ↑ Laoyan, S., (2022) Waterfall Project Management Methodology https://asana.com/resources/waterfall-project-management-methodology (Retrieved 9th April 2023)
15. ↑ Asana, T., (2021) Critical Path Method https://asana.com/resources/critical-path-method (Retrieved 9th April 2023)
16. ↑ ProjectManager.com, (2021) Gantt Chart https://www.projectmanager.com/guides/gantt-chart (Retrieved 9th April 2023)
17. ↑ Bose, S., (2022) Test Planning: A Detailed Guide. https://www.browserstack.com/guide/test-planning (Retrieved 9th April 2023)
18. ↑ Keup, M., (2021) Understanding Project Management Success Criteria. https://www.projectmanager.com/blog/understanding-project-management-success-criteria (Retrieved 6th May 2023)
19. ↑ Simplilearn, (2023) Understanding Project Success Criteria with Examples. https://www.simplilearn.com/tutorials/project-management-tutorial/project-success-criteria (Retrieved 6th May 2023)
20. ↑ Simplilearn, (2023) What is a Deliverable? https://www.simplilearn.com/what-is-a-deliverable-article (Retrieved 9th April 2023)
21. ↑ York, A., (2021) Project Deliverables https://www.teamwork.com/blog/project-deliverables/ (Retrieved 9th April 2023)
22. ↑ Hartney, J., (2019), How to Use a RACI Chart to Simplify Responsibilities, https://www.projectengineer.net/how-to-use-a-raci-chart-to-simplify-responsibilities/, (Accessed 7th may 2023)
23. ↑ Friedman, S. (2008). Roles, responsibilities, and resources: best practices in managing people. Paper presented at PMI® Global Congress 2008—North America, Denver, CO. Newtown Square, PA: Project Management Institute. (Retrieved 7th May 2023)
24. ↑ Martins, J., (2022) RACI Chart https://asana.com/resources/raci-chart (Retrieved 9th April 2023)
25. ↑ Goudie, A., (2022) What is project governance and why is it important? https://www.ninefeettall.com/what-is-project-governance-and-why-is-it-important/. (Retrieved 7th May 2023)
26. ↑ Clayton, M., (2022) What Does Project Governance Really Mean? https://www.projectmanager.com/blog/what-does-project-governance-really-mean. (Retrieved 7th May 2023)
27. ↑ ^{27.0 27.1 27.2} Alie, S. S. (2015). Project governance: #1 critical success factor. Paper presented at PMI® Global Congress 2015—North America, Orlando, FL. Newtown Square, PA: Project Management Institute. (Retrieved 7th May 2023)
28. ↑ Project Management Qualification, (2022) What is project governance?https://www.projectmanagementqualification.com/blog/2019/07/23/project-governance-explained/. (Retrieved 7th May 2023)
29. ↑ Previde, S. H. (2012). Framework for delivering higher quality statements of work for outsourced software development project. Paper presented at PMI® Global Congress 2012—North America, Vancouver, British Columbia, Canada. Newtown Square, PA: Project Management Institute. (Retrieved 7th May 2023)