Please login or join to subscribe to this thread
It depends. Does the other party operate as two separate legal entities in Canada and the U.S., or as a single entity? If the latter, then a single SoW would likely suffice and you'd just need to indicate where there is country-specific content (e.g. scope inclusions/exclusions, terms/conditions).
Gerald, a Scope of Work doesn’t change based on the location if the project is the same. Does it ? Contracts might be different and they will be for different countries. That’s my opinion.
You can develop a SOW any number of ways. It could have a branch in the WBS for each country, There could be separate line items down lower in the WBS for duplicate activities in each country, or there may be administrative reasons why it might need to be completely separate like accounting rules or specifics of your own business systems..
SOW depends on the work to be requested, not about the legal conditions or something tied to local assumptions and constraints. At lease, that´s my personal experience along the years including today where I am working inside a multinational company but we create one and only one SOW.
For what it might be useful, here are some basic ideas of what is to be included in a project's Scope of work (SOW).
According to the PMI’s PMBoK, Project Scope Statement is the narrative description of the project scope, including major deliverables, project objectives, assumptions, constrains and a statement of work that provides a documented basis for making future project decisions and for confirming or developing a common understanding of the project scope among the stake holders. The definition of the project scope – what needs to be accomplished.
A clear, well written SOW needs to be established at the very beginning of the project implementation phase, since it is crucial to the possibility of arriving at well informed decisions during the project life cycle. The more information that can be obtained in the early stages of a project, it will be more flexible in dealing with difficulties that might, and most probably will appear during the project execution.
The project SOW is created to establish a clear understanding of the projects objectives, between the project team and the Client, by identifying, and relating the work to be performed as past of the project to the Client’s goals. This way both parties agree on the needs or issues to be resolved by the project, what the deliverables will include, and the potential risks, assets, and success measures to look at.
Besides the Discipline’s specific SOW to be included in the DBM, at the project beginning a General Project SOW will be defined.
The scope definition section details the process of developing a detailed description of the project and its deliverables, after the requirements have been identified and defined.If other documents such as the Project Charter, Preliminary Project Scope Statement or Requirements Documentation were used, they should be identified in this phase.
The tools and techniques used to define the project scope such as expert judgment, product analysis, alternatives identification or facilitated workshops should also be documented.
The project description and deliverables are to be developed based on the requirements defined for the project and input from all the disciplines involved in the project and expert personnel as established in TR Canada Interdisciplines Review procedures. This review/checking process will provide feedback on the most effective ways to meet the original requirements.
Hope it helps.
Often, SoW is used to mean Statement of Work, rather than Scope. That is the narrative work statement that describes the tasks to be completed at each level of the WBS. My understanding is that the PMBOK refers to the statement of work as the WBS dictionary.
This is an area where I think PMI diverges somewhat from related bodies of knowledge. The SEBoK which I believe in many ways is the source material for the PMBoK, defines it as Statement, not Scope.
I point this out simply because in my experience, a common source of disagreement can come from when two people use the same term to describe different things. I know I've personally answered questions before using definitions accepted elsewhere that don't match the PMBoK, leading to confusion.
It's a good example of why spelling out acronyms is valuable to ensure others are reading your meaning the same way as intended.
In the recent PMBoK ed6,
- SOW is defined as 'statement of work' - a narrative description of results, products or services to be delivered by the project.
- In contrast, a project scope statement is defined as the description of project scope, major deliverables, assumptions and constraints.
- SOW in this PMBoK only occurs in procurement, the SOW is created by the buyer and used as requirements by the seller to create a proposal.
- The scope statement is created by the seller, the project delivery organization.
The SOW is what the customer wants, the scope statement is what the PM promises.
I would think t depends on the scope's interaction with government authorities (Codes), culture and local conditions/customs. With infrastructure projects architectural and engineering vary significantly from jurisdiction to jurisdiction and a common Statement of Work may be difficult to achieve.
In Canada it is normal to use the Statement of Work to define the technical requirements under contract and is developed in the early stages of the procurement process. Using 'Statement of Work' in a project management sense could be misleading as a contract Statement of Work typically does not include the entire project scope - multiple contracts each delivering specific project deliverables is more common.
A definition of what you mean by SOW would be helpful.
Please login or join to reply