What is it?
It’s common to find some confusion about terms in the industry. “Project Charter”, the “Scope”, “Statement of Work”, “Scope of Work”, the “brief”, the “contract”, or the “business case” are normally called to refer to the scope of a particular project.
They are all related, but they don’t serve the same purpose or have the same meaning. I will explain the “sales” deliverables in another post since I think I need more space to explain their importance.
So, taking into consideration the definitions from the PMI (Project Management Institute) in simple words:
Project Charter:
This is the document that marks the beginning of a project. It contains the “why” we are doing this project, the initial requirements to satisfy the stakeholders’ needs and expectations, and a high-level product description.
It also defines who the stakeholders are, the project manager, and even the team members for a project.
Statement of Work (SOW):
Also known in the industry as “Scope of Work”, it describes the products, services, or results to be delivered by the project.
To make it, you’d need the project charter or the information a project charter would contain (why are we starting this project – business’s needs / strategic alignment), the stakeholder’s register (who are your stakeholders), initial requirements, and organizational processes assets*
The main difference between these two documents is that the Project Charter explains the project with a “high-level” view of whether the Statement of Work (SOW) goes into the details of the project; it includes deliverables, assumptions, timelines, etc.
Why is an SOW important?
The SOW will define the scope of the project. It helps the project managers & the team to develop more detailed planning. It provides direction to the team through execution since it explains why a project is being initiated and what the project is expected to deliver.
It allows the stakeholders to be on the same page since it helps to set expectations on what the project will deliver and what will not. And it can facilitate any change request (deviation from the initial scope).
What to include?
The SOW can be as detailed as the project requires it to be. This is a tricky question since too much detail in the SOW could let up to “way too strict” processes without any room for change and innovation, and a way “too open” SOW can lead to misinterpretation and conflict among project stakeholders (e.g. agencies & clients).
As a minimum, the SOW should contain the following:
Project Background:
Can include some information about the industry, the suppliers selected for this project, who is the final user/customer, why the project is being started, who the client is, and any other relevant information that can help to understand the environment of the project.
Project Summary:
Short explanation of what the project is about and can include the main objectives of the project.
Description of the product or service:
Explains the characteristics of the product, service, or results to be delivered by the project. These characteristics can be as specific as the project requires. Some considerations and examples:
- This section can include the responsibilities and characteristics of the project. For example – the client will be responsible for providing all the designs of the project before the beginning of the project.
- Can include processes to follow – For example, what will be the process to follow in case of a change?
- This can include the project management approach – For example, if we are going to follow a waterfall approach or an agile approach.
- Any other relevant information – For example, working hours. When we are managing globalized projects, it’s relevant to include at what time the activities of the project are going to happen.
Acceptance Criteria
Explains what will be the processes and criteria we need to comply with for this project to be completed. (e.g., the project needs to successfully pass a certain security compliance testing).
Project deliverables:
Throughout my career, I’ve heard a lot among different people that the deliverables of the project are the products or services that this project delivers. Nevertheless, the deliverables of a project also include any ancillary results, for example, functional specifications, workflows, the RACI matrix, and others. It’s important to define from the very beginning what we are going to deliver for this project to set stakeholders’ expectations.
Exclusions / Out of scope:
Specifically states what will not be included in the project. This section will help to set the stakeholders’ expectations.
This section can open a discussion with some stakeholders; it’s better to have them now and come to an agreement rather than during the execution of the project.
Constraints:
All projects have constraints. Currently, The PMI considers six:
- Time – When the project has a due date. For example, if a project needs to be released to the public (go-live) by a certain date.
- Cost – Looked at by the stakeholders as much as the Time measurement. Represents how much we are paying for the benefits we are getting.
- Scope – We asked for particular items, and we expect to get them, no more or less. The RACI matrix can help us to bring some “scope tolerance if necessary”. For example, if we are setting up an agile project, we could include items like: “If we got time on the last sprint, we would include this particular feature”.
- Quality – Also known as “quality tolerance”, refers to the characteristics of a deliverable. For example, we might ask within a project to use a particular material, supplier, dimensions, or others.
- Benefits – Refers to the value a deliverable produces. For example, a project might deliver a new website, but the expected value can be an increase of 20% in sales.
- Risks – Risk refers to “opportunities” as well as “threats” on a project. According to its impact, a risk can even stop the project. For example, if a competitor releases the same product into the market before the project release.
Assumptions:
These are the assumptions we are considering for this project. This section is important because it helps stakeholders to be on the same page. For example, if a client is a group of companies, will this SOW affect only one company? The entire group? Is there any license involved? And if that is the case, who will expend those licenses? Similarly, we should include the use of any third party.
It can also include:
Stakeholders, Project Managers & Approvals – Traditionally included in the Project Chapter. This information is useful to have in the SOW because it defines who is going to be in charge of approving the deliverables of the project & who the project manager is of each party is; it can also include information about the project management team and escalation procedures.
References to other documents – Like the contract, the initial risk assessment, the functional specification (if it exists at this point of the project), and any other that will help to clarify the scope of the project.
Milestones, Schedule, or Initial Timelines– We can take this information from our initial estimates and modify them if necessary.
Fees / Invoicing Schedule – Includes the scheduling of payments. For example, the invoices for a project can be aligned with the deliverables of the project.
Dictionary – Relevant in those projects using several acronyms or technical words that would have different meanings for different stakeholders.
Final thoughts
The Statement of Work (SOW) is a document that will help us and our stakeholders to be on the same page from the very beginning of the project. So please feel free to include as much or as little information as you see fit, every project is different, and they have its own necessities; it’s up to you, SPM, to define what you and your project need.
Organizational processes assets are “the plans, processes, policies, procedures, and knowledge bases specific to and used by the performing organization”.
References:
Siegelaub, J. M. (2007). Six (yes six!) constraints: an enhanced model for project control. Paper presented at PMI® Global Congress 2007—North America, Atlanta, GA. Newtown Square, PA: Project Management Institute.
(2004). A guide to the project management body of knowledge (PMBOK guide). APA (6th ed.) Newtown Square, Pa: Project Management Institute.
