Getting to the Scope Baseline
As previously discussed, everyone in the project is a customer and a supplier at the same time, including the owner who is a supplier to the operation department in his company or any other end user.
The key topic in any contract between two parties is to define the scope. As defined by PMPBOK, the term scope may refer to the following:
• Product scope, which includes the features and functions that characterize a product or service
• Project scope, which is the work that must be done to deliver a product with the specified features and function to the end user
The product, which will be delivered through the project, should satisfy both the customer and the stakeholder.
The scope should be prepared after clearly defining all the stakeholders. Take more time in this stage, because, in most projects, the scope baseline takes weeks, or even months, not days, to finish. Take ideas as needed from the key persons who are sharing in the project, so that they are satisfied with the scope as it is and won’t demand changes to it later.
So, after many meetings reduce the unnecessary items from the scope, or define part of the scope to the supplier so that the scope baseline is documented and approved by the concerned stakeholder.
After you define the scope of work, be sure it is clear to the supplier who will provide this service. You should use any communication and skills necessary to make the scope of work clear to the supplier. An engineering company will provide a list of deliverables. After you send the company the scope, be sure that the deliverables match with your requirements and that everyone has read any statement based on his or her background and previous experience.
It is better to return to similar projects and look at the work break down structure (WBS), and then review if you are missing anything from the deliverables list. In major projects, every discipline should review the deliverables list received.
This document needs to be clear because it will be read by many people. The SOW is the most important part of the statement of
requirement document (SOR), because most of the conflict in any project is due to a misunderstanding of the scope of work. In some cases, the supplier may provide a small user manual to use for maintenance service. On the other hand, the operation and maintenance engineers may be waiting to receive a comprehensive user guide as they have a full responsibility to do the maintenance in house and avoid using the supplier in minor maintenance situations based on their policy, or they are afraid that the supplier will be out of business or has merged with another company, which traditionally happens. After receiving this manual, you may be in crisis because the supplier is doing what you are requesting, but the end user is not satisfied. In this case, you will change the order. From this example in the deliverable list, the contractor will deliver the "user manual" but it is different from the stakeholder’s expectation.
This situation is repeated many times in oil and gas projects. However, if we apply the whole building commissioning system methodology, as presented and discussed deeply in Chapter 8, these problems may not occur. The acceptance criteria, the test procedure, and criteria should be defined in the scope of work. So try all of the deliverables that are tangible and measurable items that can be easily understood.