Statement of Work

From apppm
(Difference between revisions)
Jump to: navigation, search
(→‎Purpose and importance of the SoW document)
(→‎Project Organization)
 
(353 intermediate revisions by one user not shown)
Line 1: Line 1:
 +
 +
''Developed by Abiha Tasneem''
  
 
== Abstract ==
 
== 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.
+
Scope creep is a common challenge faced by project managers and to mitigate it, project managers can use a Statement of Work (SoW) document which outlines the scope of customer engagement in a formal and structured way. 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. Best practices are shared on how to write the SoW using concise language and how project complexity affects the structure of the SoW. Finally, the wiki article wraps up with limitations on the SoW and 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 it, and suggestions on how to mitigate it.
 +
 
 +
=== Scope Creep Definition and Causes ===
 +
The Project Management Body of Knowledge (PMBOK) Guide defines scope creep as:
 +
 
 +
"''The uncontrolled expansion to product or project scope without adjustments to time, cost, and resources <ref name ="PMBOK"></ref>.''"
 +
 
 +
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 and negatively affects the time, cost, and quality of a project <ref> Ajmal, M., Khan, M., & Al-Yafei, H. (2019). Exploring factors behind project scope creep – stakeholders’ perspective. International Journal of Managing Projects in Business, 13(3), 483-504. (Accessed: 5th May 2023)</ref>.  Scope creep can occur at any time during a project, but some stages of the project are more vulnerable to being affected, e.g., during the project's initial phases, when clients ask for more additions, or once a deadline is missed. 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 <ref name="PMI"> 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)</ref>.
 +
 
 +
According to Larson, R. & Larson, E. <ref name="PMI"></ref>, the top five reasons why scope creep occurs are:
 +
* Ambiguous or unrefined scope definition
 +
* Lack of any formal scope or requirements
 +
* Inconsistent process for collecting product requirements
 +
* Lack of sponsorship and stakeholder involvement
 +
* Project length
 +
 
 +
To avoid scope creep, project managers must proactively manage the project scope, monitor project activities, and adhere to established change management procedures.
 +
 
 +
=== How To Mitigate 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.  Larson, R. & Larson, E. <ref name="PMI"> </ref> has suggested numerous mitigating actions for each of the causes, some of which are stated below:
 +
 
 +
'''Ambiguous or unrefined scope definition:'''
 +
* Create a 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
 +
* 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
 +
 
 +
'''Project length:'''
 +
* Educate sponsors to chunk projects into shorter subprojects
 +
* Decompose projects into smaller subprojects
 +
 
 +
The SoW document is a helpful tool to decrease the probability of scope creep <ref name = "SOW"> Martin, M. G. (1998). Statement of work: the foundation for delivering successful service projects. PM Network, 12(10), 54–57. (Accessed: 5th May 2023)</ref>. In the rest of this wiki article, there will be an in-depth review of the SoW document, exploring what it is, its importance in project management, and recommendations on how to structure it effectively.
 +
 
 +
== 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 <ref name = "SOW"></ref>. 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 <ref name = "SOW"></ref>. This is where a Statement of Work (SoW) document comes in. The SoW is a formal document that defines the scope of customer engagement and is mainly developed with input from relevant stakeholders (e.g., sales team, installation team, customer, etc.). This section will dive deeper into the definition, purpose, and importance of the SoW document.
 +
 
 +
=== Definition and Purpose ===
 +
 
 +
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 <ref name ="PMBOK"> Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute. (Accessed: 5th May 2023)</ref>.''”
 +
 
 +
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)<ref name ="SOW"></ref>. 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 <ref name ="PMBOK"></ref>.''"
 +
 
 +
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 is mainly developed when dealing with systems that require installation and project management expertise.
 +
 
 +
=== 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 the project team and the 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<ref name = "SOW"></ref>. 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, it is believed that the SoW decreases the probability of scope creep <ref name = "SOW"> </ref>, which is a common problem in project management. The SoW document helps to prevent scope creep by clearly defining the project's scope and limiting changes to it.
 +
 
 +
== Key Elements of The SoW Document ==
 +
 
 +
This section will provide a detailed description of each of these components, highlighting their importance in developing a well-structured SoW document. The structure and content of a SoW can vary depending on the project and the needs of the customer. 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 recommended that the SoW document should include the following key sections in the document:
 +
 
 +
*'''Introduction'''
 +
*'''Solution Definition'''
 +
*'''Project Deliverables'''
 +
*'''Project Organization'''
 +
*'''Project Governance'''
 +
*'''Review and Signature Page'''
 +
 
 +
In the following section, each of these key elements will be elaborated, 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. In this section, there is an opportunity to explain what type of work that is being executed and general information about the project <ref name="Landau"></ref>. It is recommended that the introduction section covers the following areas, executive summary, purpose statement, and brief project schedule.
 +
 
 +
'''Executive Summary'''
 +
 
 +
An executive summary is a brief overview of a full document designed to give readers a quick preview of its contents and should be included in the SoW. Its primary purpose is to summarize the document's key points and present them in a consolidated format <ref> Howe Writing Initiative. (2010). Miami School of Business. Farmer School of Business. (Accessed: 6th May 2023)</ref>.
 +
 
 +
'''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 <ref name="Landau"></ref>.
 +
 
 +
'''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 <ref name="Landau"> Landau P., (2023) What Is a Statement of Work? Definition & Examples. Available at: https://www.projectmanager.com/blog/statement-work-definition-examples (Accessed: 6th May 2023)</ref>. Having a brief schedule can help identify any potential scheduling conflicts or delays early on in the project, allowing for proactive mitigation strategies to be put in place.
 +
 
 +
=== Solution Definition ===
 +
 
 +
The Solution Definition is a detailed description of the solution that will be provided to the customer. It is recommended that the solution definition section in the SoW contain the following areas: project objectives, requirements specification, project planning approach, system testing, success criteria, and transition to support.
 +
 
 +
'''Project Objectives'''
 +
 
 +
According to the Project Management Body of Knowledge (PMBOK) Guide, 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 name ="PMBOK"></ref>.''"
 +
 
 +
This section in the SoW should contain a description of the high-level objectives of the project. To write down some ideal project objectives in an effective manner, it is recommended that the project manager uses the SMART methodology. According to the Project Management Institute <ref name = "SMART"> 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. (Accessed: 9th April 2023)</ref>, '''SMART''' stands for:
 +
 
 +
*'''S'''pecific - the objective is clearly stated
 +
*'''M'''easurable - metrics exist to determine when the objective has been met
 +
*'''A'''chievable - the team agrees the objective is realistic
 +
*'''R'''elevant - the objective fits the organization's strategic plan and supports the project charter
 +
*'''T'''ime-bound - a date for achieving the objective is stated
 +
 
 +
By using the SMART methodology the project manager ensures having clear goals which ultimately increases persistence and self-efficacy <ref> Grimm, P. (2023). SMART goals in project planning and performance management, APPPM Wiki Article. Available at: http://wiki.doing-projects.org/index.php/SMART_goals_in_project_planning_and_performance_management. (Accessed: 8th May 2023)</ref>.
 +
[[File:RTM.png|thumb|350px|Figure 1: Example of a Requirements Traceability Matrix <ref name="PMBOK"></ref>.]]
 +
'''Requirements Specification'''
 +
 
 +
A requirements specification is important to include in the SoW as it provides a concise overview of the project's requirements by involving the use of grids, flow charts, and diagrams <ref name = "requirements"> Foster, Elvis C., (2014). Software Engineering A Methodical Approach. 61-68. (Accessed: 9th April 2023)</ref>. It is recommended that the project manager develops a requirements traceability matrix as shown in figure 1. A requirements traceability matrix is a grid that links product requirements from their origin to the deliverables that satisfy them <ref name = "PMBOK"></ref>. In the implementation of a requirements traceability matrix, the project manager ensures that each requirement adds business value by linking it to the project objectives <ref name = "PMBOK"></ref>. Furthermore, the requirements specification should be developed in collaboration with the customer. 
 +
 
 +
'''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> Steven, F., (2010) Credit Scoring, Response Modelling, and Insurance Rating. (Accessed: 9th April 2023)</ref>. 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, Agile Planning, Waterfall Planning, Critical Path Method Planning, and Gantt Chart Planning <ref name = "PMBOK"></ref>. There are several approaches to project planning, however, the aforementioned 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, 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 <ref name ="PMBOK"></ref>.''"
 +
 
 +
The purpose of this section in the SoW is to write down all the details regarding testing the system in cooperation with the relevant stakeholders, i.e., developing a test plan. The purpose 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.
 +
 
 +
According to Bose, S. <ref> Bose, S., (2022) Test Planning: A Detailed Guide. Available at: https://www.browserstack.com/guide/test-planning (Accessed: 9th April 2023)</ref>, it is recommended that the systems test plan is developed to contain the following components:
 +
 
 +
* 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 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 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 <ref> Keup, M., (2021) Understanding Project Management Success Criteria. Available at: https://www.projectmanager.com/blog/understanding-project-management-success-criteria (Accessed: 6th May 2023)</ref>. It is recommended that the project manager create a list of success criteria based on Shokri-Ghasabeh & Kavousi-Chabok's <ref> Shokri-Ghasabeh, M., & Kavousi-Chabok, K., (2009). Generic Project Success and Project Management Success Criteria and Factors: Literature Review and Survey. The University of South Australia. (Accessed: 9th May 2023)</ref> review of success criteria for projects: time, cost, quality, project control, project scope, stakeholder satisfaction, resources, project team, and risk management.
 +
 
 +
'''Transition to Support'''
 +
 
 +
When the system is installed, a transition to a support meeting will be facilitated. The transition to support section is an important part of a SoW because it outlines the process for transferring the responsibility of the project from the project team to the support team.
 +
 
 +
=== Project Deliverables ===
 +
 
 +
The Project Management Body of Knowledge (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 name = "PMBOK"></ref>.''"
 +
 
 +
[[File:Deliverables.png|thumb|350px|Figure 2: Example: Table of Deliverables.]]
 +
 
 +
In this section of the SoW all the deliverables of the project are detailed. 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  <ref> York, A., (2021) Project Deliverables. Available at: https://www.teamwork.com/blog/project-deliverables/ (Accessed: 9th April 2023)</ref>.
 +
 
 +
Figure 2 shows an example of how it is recommended that the project manager specifies the deliverables of the project. This can be done by creating a table with all deliverables of the project listed where the first column is a description of the deliverable and the second column is the completion criteria of the given deliverable.
 +
 
 +
=== Project Organization ===
 +
[[File:raci-chart.png|thumb|350px|Figure 3: Example: RACI Chart.<ref name="figure3">Hartney, J., (2019), How to Use a RACI Chart to Simplify Responsibilities. Available at: https://www.projectengineer.net/how-to-use-a-raci-chart-to-simplify-responsibilities/ (Accessed: 7th may 2023)</ref>]]
 +
 
 +
The Project Organization is a section in the SoW that describes 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 <ref name = "PMBOK"></ref>. 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 <ref name = "RACI"> 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. (Accessed: 7th May 2023)</ref>.
 +
 
 +
A '''RACI''' structure refers to:
 +
 
 +
* '''R'''esponsible
 +
* '''A'''ccountable
 +
* '''C'''onsulted
 +
* '''I'''nformed
 +
 
 +
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, ensuring accountability, and facilitate communication <ref name = "RACI"></ref>.
 +
 
 +
=== Project Governance ===
 +
 
 +
Project governance is an important aspect of a SoW document because it entails all the key elements that make a project successful <ref name = PMI1></ref>.
 +
The Project Management Body of Knowledge (PMBOK) Guide defines project governance as:
 +
 
 +
''"Project governance refers to the framework, functions, and processes that guide project management activities in order to create a unique product, service, or result to meet organizational, strategic, and operational goals <ref name = "PMBOK"></ref>."''
 +
 
 +
Some of the roles that are a necessity for establishing and maintaining project governance are sponsors, steering committee, project management office, and project manager <ref name = PMI1> 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. (Accessed: 7th May 2023)</ref>.
 +
 
 +
Project governance should cover the following aspects <ref name = "PMBOK"></ref>.:
 +
* Rules
 +
* Policies
 +
* 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 <ref name = PMI1></ref>. 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 influences how objectives are set, risk is monitored and performance is optimized <ref name = PMBOK></ref>.
 +
 
 +
=== Review and Signature Page ===
 +
Lastly and most importantly, closure is needed by having the customer sign off the SoW document <ref name="Landau"></ref>. 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.  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 <ref name = "PMI2"> 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. (Accessed: 7th May 2023)</ref>.
 +
 
 +
== Best Practices ==
 +
In this section, the best practices will be shared regarding how to use concise language in the SoW and how the project complexity level can impact the SoW document.
 +
 
 +
=== Concise language ===
 +
According to Previde, S. H. <ref name = "PMI2"></ref>, there are some aspects that need to be considered as best practices when writing the SoW document:
 +
 
 +
* Use simple and direct language for clarity
 +
* Use active voice
 +
* Use positive words
 +
* Use technical language sparingly
 +
* Define acronyms and abbreviations
 +
* Make the SoW easy to read by following general writing considerations
 +
* Avoid vague or obscure words and phrases
 +
* Avoid terms that are specific to an industry or organization that may not be understood universally
 +
* Avoid redundancy
 +
* Avoid big or complex words
 +
* Avoid words or statements that are difficult or impossible to quantify
 +
 
 +
The best practices are listed briefly above, to read further please visit the reference <ref name = "PMI2"></ref>.
 +
[[File:complexity_level.png|thumb|250px|Figure 4: Complexity Level Impact on SoW.]]
 +
 
 +
=== Project Complexity Level Impact ===
 +
 
 +
When writing a SoW document, the complexity level of the project plays an important role in determining the structure of the document.  Figure 4 illustrates that larger (integrated), projects require a higher level of detail to be formalized in the SoW document, while smaller (foundation), projects may require less detail. The primary objective is to create a SoW document that is tailored to the project's complexity level.
 +
 
 +
An example of how the complexity level affects the structure of the SoW can for example be observed in the scope of work. As the complexity level increases, the number of interdependent tasks also increases. This means that the scope of work needs to be more detailed as well when writing the SoW.  
  
−
== Purpose and Importance of the SoW document ==
+
Overall, by tailoring the content of the SoW document to the complexity level of the project, project managers can ensure that the project runs smoothly, and deliver the desired outcomes within the set timelines.
  
−
A Guide to the Project Management Body of Knowledge (PMBOK Guide) defines a Statement of Work as:
+
== Limitations ==
  
−
"''A narrative description of products or services to be supplied under the contract.''”
+
The benefits of developing and using a SoW have been listed throughout this article, and while there are many benefits, there are also some limitations that need to be taken into consideration. In this section, the focus will be on three limitations of the SoW document, namely the risk of over-detailing, the risk of vague and generic detailing, and the limited flexibility.
  
−
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:
+
'''Risk of over detailing'''
  
−
''“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.''"
+
One of the limitations of creating a SoW document is the risk of going too much into detail. Creating an excessively detailed SoW document can lead to unnecessary work being undertaken simply because it was mentioned in the document. Over-detailing may occur due to the desire to provide thorough information and instructions but lead to the project being stifled <ref name ="lawbite"> LawBite, (2022) What is a Statement Of Work. Available at: https://www.lawbite.co.uk/resources/blog/what-is-a-statement-of-work (Accessed: 6th May 2023)</ref>. Therefore, it is important for a project manager to assess which parts of a SoW are important to the given project they are working on.
  
−
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.
+
'''Risk of vague and generic detailing'''
  
−
== Key elements of the SoW document ==
+
Another limitation is that there is a risk of details concerning tasks, work practices, and deliverables becoming too broad, vague, and generic. If details concerning tasks, work practices, and deliverables are too broad, it will not be clear what the expectations are from the project team and will lead to misunderstandings and potentially a costly legal dispute <ref name ="lawbite"></ref>.
  
−
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.
+
'''Limited flexibility'''
  
−
'''Introduction'''
+
Lastly, there is a risk of the SoW might not allow for flexibility in response to changes or unexpected events. This can entail that the project team might have to go through a formal change request to update the SoW, which can potentially lead to delays and additional costs.
  
−
Entails an executive summary and a schedule.
+
== Conclusion ==
−
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'''
+
To summarize, this wiki article has extensively addressed the phenomenon of scope creep, exploring its meaning and underlying causes. Additionally, the article has explained the importance of the Statement of Work (SoW) and its essential components. Although there exists no universal one-size-fits-all approach for developing a SoW, the article has recommended practical suggestions on the sections that a SoW should contain. This wiki article has also highlighted the significance of concise language and the influence of project complexity on the SoW. Finally, the article has culminated in a tabular representation of the causes of scope creep mentioned earlier, along with strategies for mitigating them and assessing the extent to which the SoW document fulfills those mitigation measures.
  
−
project objectives, project approach (milestone planning), system testing, customer acceptance (Acceptance and success criteria), physical location of the workplace, and transition to support.  
+
[[File:Reqreq.png|center|600px|Figure 5: Mitigating Actions Fulfilled by The SoW.]]
  
−
'''Project Deliverables'''
+
As seen in the above table, the scope creep can be mitigated through actions that are fulfilled by a SoW document, such as defining deliverables, reviewing requirements with stakeholders, incorporating a RACI chart, etc. However, some of the other cause to scope creep requires additional actions besides incorporating a SoW document, such as the development of a project status reporting tool and educating sponsors to chunk the project into shorter subprojects. The SoW document may not mitigate all the causes of scope creep but is a significant tool in preventing it, which is why it is recommended as an essential tool for project managers.
  
−
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[https://www.simplilearn.com/what-is-a-deliverable-article]. 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 [https://www.teamwork.com/blog/project-deliverables/]. 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.
+
== Annotated Bibliography ==
 +
To obtain additional information on this topic, it is recommended to read the key references in the annotated bibliography.
  
 +
'''Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute.'''
  
−
'''Project Organization'''
+
The Project Management Body of Knowledge (PMBOK Guide) is a collection of project management processes, best practices, terminologies, and guidelines. To gain additional insight on some of the topics that haven't been elaborated further in this article, the reader can with advantage look up the different topics in this book.
  
−
Roles and responsibilities (RACI), work roles and responsibilities
+
'''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.'''
  
−
'''Project Framework'''
+
This paper by Larson, R. & Larson, E. covers the five most common causes of scope creep and what project managers can do about these. Furthermore, there is a case study of scope creep that can be read to gain in-depth knowledge about the different elements of scope creep.
  
−
Governance
+
'''Martin, M. G. (1998). Statement of work: the foundation for delivering successful service projects. PM Network, 12(10), 54–57.'''
−
Constraints
+
  
−
== Project complexity level impact on SoW ==
+
This paper discusses the importance of having a detailed SoW for project managers and customers in order to prevent project failure. Martin, M. G. discusses how the SoW establishes the foundation of the project and how it helps provide all parties with an objective measurement of work that is completed throughout the project.
−
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''
+
'''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.'''
  
−
== Strategies for preventing scope screep ==
+
This paper covers the importance of clearly defined roles and responsibilities which is an essential part to cover in the SoW document. In the paper, Friedman, S. offers advice for how project managers can identify and address issues within people management. The RACI chart is also elaborated further in this paper.
−
''Bullet points of the areas the author wants to dive deeper into:''
+
  
−
* What is scope creep?
+
'''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.'''
−
* 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 ==
+
This paper by Alie, S. S. investigates the critical success factors for project governance. This paper is beneficial if the reader would like to gain additional knowledge on how project governance can be assessed.
−
''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?
+
==References==
−
* Stakeholder involvement - which parties were involved?
+
<references/>
−
* Monitoring of the project with the help of SoW document - how was it done?
+
−
* Detailing how the SoW contributed to a succesful project execution.
+

Latest revision as of 22:21, 9 May 2023

Developed by Abiha Tasneem

Contents

[edit] Abstract

Scope creep is a common challenge faced by project managers and to mitigate it, project managers can use a Statement of Work (SoW) document which outlines the scope of customer engagement in a formal and structured way. 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. Best practices are shared on how to write the SoW using concise language and how project complexity affects the structure of the SoW. Finally, the wiki article wraps up with limitations on the SoW and a conclusion on how the SoW helps prevent scope creep.

[edit] 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 it, and suggestions on how to mitigate it.

[edit] Scope Creep Definition and Causes

The Project Management Body of Knowledge (PMBOK) Guide defines scope creep as:

"The uncontrolled expansion to product or project scope without adjustments to time, cost, and resources [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 and negatively affects the time, cost, and quality of a project [2]. Scope creep can occur at any time during a project, but some stages of the project are more vulnerable to being affected, e.g., during the project's initial phases, when clients ask for more additions, or once a deadline is missed. 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 [3].

According to Larson, R. & Larson, E. [3], the top five reasons why scope creep occurs are:

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

To avoid scope creep, project managers must proactively manage the project scope, monitor project activities, and adhere to established change management procedures.

[edit] How To Mitigate 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. Larson, R. & Larson, E. [3] has suggested numerous mitigating actions for each of the causes, some of which are stated below:

Ambiguous or unrefined scope definition:

  • Create a 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
  • 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

Project length:

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

The SoW document is a helpful tool to decrease the probability of scope creep [4]. In the rest of this wiki article, there will be an in-depth review of the SoW document, exploring what it is, its importance in project management, and recommendations on how to structure it effectively.

[edit] 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 [4]. 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 [4]. This is where a Statement of Work (SoW) document comes in. The SoW is a formal document that defines the scope of customer engagement and is mainly developed with input from relevant stakeholders (e.g., sales team, installation team, customer, etc.). This section will dive deeper into the definition, purpose, and importance of the SoW document.

[edit] Definition and Purpose

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

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

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 is mainly developed when dealing with systems that require installation and project management expertise.

[edit] 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 the project team and the 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[4]. 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, it is believed that the SoW decreases the probability of scope creep [4], which is a common problem in project management. The SoW document helps to prevent scope creep by clearly defining the project's scope and limiting changes to it.

[edit] Key Elements of The SoW Document

This section will provide a detailed description of each of these components, highlighting their importance in developing a well-structured SoW document. The structure and content of a SoW can vary depending on the project and the needs of the customer. 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 recommended that the SoW document should include the following key sections in the document:

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

In the following section, each of these key elements will be elaborated, along with recommendations on how to structure and present them effectively.

[edit] Introduction

Having an introduction section in the SoW document is important because it sets the stage for the entire document. In this section, there is an opportunity to explain what type of work that is being executed and general information about the project [5]. It is recommended that the introduction section covers the following areas, executive summary, purpose statement, and brief project schedule.

Executive Summary

An executive summary is a brief overview of a full document designed to give readers a quick preview of its contents and should be included in the SoW. Its primary purpose is to summarize the document's key points and present them in a consolidated format [6].

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

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

[edit] Solution Definition

The Solution Definition is a detailed description of the solution that will be provided to the customer. It is recommended that the solution definition section in the SoW contain the following areas: project objectives, requirements specification, project planning approach, system testing, success criteria, and transition to support.

Project Objectives

According to the Project Management Body of Knowledge (PMBOK) Guide, 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 [1]."

This section in the SoW should contain a description of the high-level objectives of the project. To write down some ideal project objectives in an effective manner, it is recommended that the project manager uses the SMART methodology. According to the Project Management Institute [7], SMART stands for:

  • Specific - the objective is clearly stated
  • Measurable - metrics exist 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 having clear goals which ultimately increases persistence and self-efficacy [8].

Figure 1: Example of a Requirements Traceability Matrix [1].

Requirements Specification

A requirements specification is important to include in the SoW as it provides a concise overview of the project's requirements by involving the use of grids, flow charts, and diagrams [9]. It is recommended that the project manager develops a requirements traceability matrix as shown in figure 1. A requirements traceability matrix is a grid that links product requirements from their origin to the deliverables that satisfy them [1]. In the implementation of a requirements traceability matrix, the project manager ensures that each requirement adds business value by linking it to the project objectives [1]. Furthermore, the requirements specification should be developed in collaboration with the customer.

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 [10]. 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, Agile Planning, Waterfall Planning, Critical Path Method Planning, and Gantt Chart Planning [1]. There are several approaches to project planning, however, the aforementioned 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, 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 [1]."

The purpose of this section in the SoW is to write down all the details regarding testing the system in cooperation with the relevant stakeholders, i.e., developing a test plan. The purpose 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.

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

  • 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 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 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 [12]. It is recommended that the project manager create a list of success criteria based on Shokri-Ghasabeh & Kavousi-Chabok's [13] review of success criteria for projects: time, cost, quality, project control, project scope, stakeholder satisfaction, resources, project team, and risk management.

Transition to Support

When the system is installed, a transition to a support meeting will be facilitated. The transition to support section is an important part of a SoW because it outlines the process for transferring the responsibility of the project from the project team to the support team.

[edit] Project Deliverables

The Project Management Body of Knowledge (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 [1]."

Figure 2: Example: Table of Deliverables.

In this section of the SoW all the deliverables of the project are detailed. 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 [14].

Figure 2 shows an example of how it is recommended that the project manager specifies the deliverables of the project. This can be done by creating a table with all deliverables of the project listed where the first column is a description of the deliverable and the second column is the completion criteria of the given deliverable.

[edit] Project Organization

Figure 3: Example: RACI Chart.[15]

The Project Organization is a section in the SoW that describes 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 [1]. 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 [16].

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, ensuring accountability, and facilitate communication [16].

[edit] Project Governance

Project governance is an important aspect of a SoW document because it entails all the key elements that make a project successful [17]. The Project Management Body of Knowledge (PMBOK) Guide defines project governance as:

"Project governance refers to the framework, functions, and processes that guide project management activities in order to create a unique product, service, or result to meet organizational, strategic, and operational goals [1]."

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

Project governance should cover the following aspects [1].:

  • Rules
  • Policies
  • 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 [17]. 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 influences how objectives are set, risk is monitored and performance is optimized [1].

[edit] Review and Signature Page

Lastly and most importantly, closure is needed by having the customer sign off the SoW document [5]. 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. 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 [18].

[edit] Best Practices

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

[edit] Concise language

According to Previde, S. H. [18], there are some aspects that need to be considered as best practices when writing the SoW document:

  • Use simple and direct language for clarity
  • Use active voice
  • Use positive words
  • Use technical language sparingly
  • Define acronyms and abbreviations
  • Make the SoW easy to read by following general writing considerations
  • Avoid vague or obscure words and phrases
  • Avoid terms that are specific to an industry or organization that may not be understood universally
  • Avoid redundancy
  • Avoid big or complex words
  • Avoid words or statements that are difficult or impossible to quantify

The best practices are listed briefly above, to read further please visit the reference [18].

Figure 4: Complexity Level Impact on SoW.

[edit] Project Complexity Level Impact

When writing a SoW document, the complexity level of the project plays an important role in determining the structure of the document. Figure 4 illustrates that larger (integrated), projects require a higher level of detail to be formalized in the SoW document, while smaller (foundation), projects may require less detail. The primary objective is to create a SoW document that is tailored to the project's complexity level.

An example of how the complexity level affects the structure of the SoW can for example be observed in the scope of work. As the complexity level increases, the number of interdependent tasks also increases. This means that the scope of work needs to be more detailed as well when writing the SoW.

Overall, by tailoring the content of the SoW document to the complexity level of the project, project managers can ensure that the project runs smoothly, and deliver the desired outcomes within the set timelines.

[edit] Limitations

The benefits of developing and using a SoW have been listed throughout this article, and while there are many benefits, there are also some limitations that need to be taken into consideration. In this section, the focus will be on three limitations of the SoW document, namely the risk of over-detailing, the risk of vague and generic detailing, and the limited flexibility.

Risk of over detailing

One of the limitations of creating a SoW document is the risk of going too much into detail. Creating an excessively detailed SoW document can lead to unnecessary work being undertaken simply because it was mentioned in the document. Over-detailing may occur due to the desire to provide thorough information and instructions but lead to the project being stifled [19]. Therefore, it is important for a project manager to assess which parts of a SoW are important to the given project they are working on.

Risk of vague and generic detailing

Another limitation is that there is a risk of details concerning tasks, work practices, and deliverables becoming too broad, vague, and generic. If details concerning tasks, work practices, and deliverables are too broad, it will not be clear what the expectations are from the project team and will lead to misunderstandings and potentially a costly legal dispute [19].

Limited flexibility

Lastly, there is a risk of the SoW might not allow for flexibility in response to changes or unexpected events. This can entail that the project team might have to go through a formal change request to update the SoW, which can potentially lead to delays and additional costs.

[edit] Conclusion

To summarize, this wiki article has extensively addressed the phenomenon of scope creep, exploring its meaning and underlying causes. Additionally, the article has explained the importance of the Statement of Work (SoW) and its essential components. Although there exists no universal one-size-fits-all approach for developing a SoW, the article has recommended practical suggestions on the sections that a SoW should contain. This wiki article has also highlighted the significance of concise language and the influence of project complexity on the SoW. Finally, the article has culminated in a tabular representation of the causes of scope creep mentioned earlier, along with strategies for mitigating them and assessing the extent to which the SoW document fulfills those mitigation measures.

Figure 5: Mitigating Actions Fulfilled by The SoW.

As seen in the above table, the scope creep can be mitigated through actions that are fulfilled by a SoW document, such as defining deliverables, reviewing requirements with stakeholders, incorporating a RACI chart, etc. However, some of the other cause to scope creep requires additional actions besides incorporating a SoW document, such as the development of a project status reporting tool and educating sponsors to chunk the project into shorter subprojects. The SoW document may not mitigate all the causes of scope creep but is a significant tool in preventing it, which is why it is recommended as an essential tool for project managers.

[edit] Annotated Bibliography

To obtain additional information on this topic, it is recommended to read the key references in the annotated bibliography.

Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute.

The Project Management Body of Knowledge (PMBOK Guide) is a collection of project management processes, best practices, terminologies, and guidelines. To gain additional insight on some of the topics that haven't been elaborated further in this article, the reader can with advantage look up the different topics in this book.

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.

This paper by Larson, R. & Larson, E. covers the five most common causes of scope creep and what project managers can do about these. Furthermore, there is a case study of scope creep that can be read to gain in-depth knowledge about the different elements of scope creep.

Martin, M. G. (1998). Statement of work: the foundation for delivering successful service projects. PM Network, 12(10), 54–57.

This paper discusses the importance of having a detailed SoW for project managers and customers in order to prevent project failure. Martin, M. G. discusses how the SoW establishes the foundation of the project and how it helps provide all parties with an objective measurement of work that is completed throughout the project.

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.

This paper covers the importance of clearly defined roles and responsibilities which is an essential part to cover in the SoW document. In the paper, Friedman, S. offers advice for how project managers can identify and address issues within people management. The RACI chart is also elaborated further in this paper.

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.

This paper by Alie, S. S. investigates the critical success factors for project governance. This paper is beneficial if the reader would like to gain additional knowledge on how project governance can be assessed.

[edit] References

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute. (Accessed: 5th May 2023)
  2. ↑ Ajmal, M., Khan, M., & Al-Yafei, H. (2019). Exploring factors behind project scope creep – stakeholders’ perspective. International Journal of Managing Projects in Business, 13(3), 483-504. (Accessed: 5th May 2023)
  3. ↑ 3.0 3.1 3.2 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)
  4. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 Martin, M. G. (1998). Statement of work: the foundation for delivering successful service projects. PM Network, 12(10), 54–57. (Accessed: 5th May 2023)
  5. ↑ 5.0 5.1 5.2 5.3 Landau P., (2023) What Is a Statement of Work? Definition & Examples. Available at: https://www.projectmanager.com/blog/statement-work-definition-examples (Accessed: 6th May 2023)
  6. ↑ Howe Writing Initiative. (2010). Miami School of Business. Farmer School of Business. (Accessed: 6th May 2023)
  7. ↑ 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. (Accessed: 9th April 2023)
  8. ↑ Grimm, P. (2023). SMART goals in project planning and performance management, APPPM Wiki Article. Available at: http://wiki.doing-projects.org/index.php/SMART_goals_in_project_planning_and_performance_management. (Accessed: 8th May 2023)
  9. ↑ Foster, Elvis C., (2014). Software Engineering A Methodical Approach. 61-68. (Accessed: 9th April 2023)
  10. ↑ Steven, F., (2010) Credit Scoring, Response Modelling, and Insurance Rating. (Accessed: 9th April 2023)
  11. ↑ Bose, S., (2022) Test Planning: A Detailed Guide. Available at: https://www.browserstack.com/guide/test-planning (Accessed: 9th April 2023)
  12. ↑ Keup, M., (2021) Understanding Project Management Success Criteria. Available at: https://www.projectmanager.com/blog/understanding-project-management-success-criteria (Accessed: 6th May 2023)
  13. ↑ Shokri-Ghasabeh, M., & Kavousi-Chabok, K., (2009). Generic Project Success and Project Management Success Criteria and Factors: Literature Review and Survey. The University of South Australia. (Accessed: 9th May 2023)
  14. ↑ York, A., (2021) Project Deliverables. Available at: https://www.teamwork.com/blog/project-deliverables/ (Accessed: 9th April 2023)
  15. ↑ Hartney, J., (2019), How to Use a RACI Chart to Simplify Responsibilities. Available at: https://www.projectengineer.net/how-to-use-a-raci-chart-to-simplify-responsibilities/ (Accessed: 7th may 2023)
  16. ↑ 16.0 16.1 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. (Accessed: 7th May 2023)
  17. ↑ 17.0 17.1 17.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. (Accessed: 7th May 2023)
  18. ↑ 18.0 18.1 18.2 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. (Accessed: 7th May 2023)
  19. ↑ 19.0 19.1 LawBite, (2022) What is a Statement Of Work. Available at: https://www.lawbite.co.uk/resources/blog/what-is-a-statement-of-work (Accessed: 6th May 2023)
Retrieved from "http://wiki.doing-projects.org/index.php?title=Statement_of_Work&oldid=147129"
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox