Scope of Work — Companion Article
What this tool does
The Scope of Work is the first piping project-control document. It states what the piping effort includes, and what it does not, so the estimate, the schedule, and every later change have a base case to stand on.
A useful scope has four parts, plus the exhibits that show which documents the scope was written from:
- Scope of facilities. Which units, areas, or systems are in the piping work, and which are out.
- Scope of services. What the piping team will do: home-office design, model, site support, or whatever this contract actually includes.
- Design development and deliverables. The documents and models the team will produce.
- Assumptions and clarifications. What you are relying on the client to supply, and the boundaries that keep the hours honest.
The exhibits name the plot, the equipment list, the P&IDs, the contract, or whatever else the scope was based on, and which revision.
When to use it
Write it at the start, before you estimate hours and before you build the control-level schedule. Approve it as the base case. After that, use it whenever someone asks whether a piece of work is included.
Piping work that was not identified in the approved scope is not started until an approved change order covers it. That rule is what keeps the estimate and the schedule meaningful.
Inputs
Bring the material the base case has to be written from:
- The facilities and battery limits in the enquiry or the contract.
- The services the piping team is expected to perform, and those that sit with others.
- The deliverables the project expects: P&IDs, plot and layout, a model, isometrics, material take-off, stress support, or site assistance, as applicable.
- Quantities you already know, such as an approximate line count, where they shape what is included.
- The assumptions: client-supplied information, revision status of the process documents, and exclusions.
- The list of source documents and their revisions, for the exhibits.
You are defining the work, not selecting catalogue components.
How it works
Draft the scope in the four parts, then test it against the work you are about to estimate.
- Write facilities first. Where the enquiry is silent about an area, say whether it is in or out.
- Write services next, so design, procurement support, and site work are not left to habit.
- List the deliverables the team will actually produce. The estimate will put hours on this list, and the schedule will put dates on it.
- Write the assumptions and clarifications in sentences a reviewer can accept or challenge. Vague assumptions become unpaid work.
- Attach the exhibits. A scope without the revision it was written against cannot support a later change.
- Check the set. Any activity you expect to estimate should be visible in the facilities, the services, or the deliverables. If it is not, either add it before approval or leave it out of the estimate.
Once it is approved, later additions, deletions, and trends are identified against this document. They are not absorbed by rewriting history.
Understanding the result
The result is an approved scope a piping lead can hand to the estimator and the scheduler. A reader should be able to answer four questions: what is in, what we will do, what we will deliver, and what we assumed.
It is the document a change is written against. If a request is already inside the four parts, it is base-scope work. If it is not, it is a change.
Engineering considerations
Be specific enough that two piping leads would draw the same boundary. “Piping design for the unit” is weaker than naming the unit, the deliverables, and the exclusions.
Keep the scope, the estimate, and the schedule in agreement. Hours for work the scope does not mention, or schedule activities the scope does not mention, mean the set is not ready to approve.
Freeze the revision you based the scope on. When the client issues a new P&ID revision, you can then say what changed relative to the exhibit, which is the start of a proper change record.
The piping lead writes and owns the piping scope. The project manager approves it as part of the project base case. It does not replace the contract. It states the piping work the contract has been read to include.
Example
Illustrative example. This is not a project record.
Part I: one process unit is in. Offsites and the tank farm are out. Part II: home-office piping design is in. Site supervision is out. Part III: the deliverables are plot arrangement, a 3D model, isometrics, and a material take-off. Stress sketches beyond what those isometrics need are out. Part IV: the client supplies the plot, the equipment list, and the P&IDs at the revision named in the exhibit. Vendor data is assumed to arrive in time for the model review on the schedule.
A later request for a new tie-in in the tank farm is not inside Part I. It is not started, and it is not given hours, until a change order covers it.
Standards and references
Based on the project-controls methodology of James O. Pennock, Piping Engineering Leadership for Process Plant Projects. The four-part scope is the base case in that method. It is a practical document for a piping engineering lead. It is not an ASME or API code, and it is not a substitute for the contract or your company procedure.
Limitations and disclaimer
This tool helps you write and hold the piping scope of work. It does not replace the contract, the client’s scope, or your company’s approved procedure. It does not set a universal allowance for missing information. Work outside the approved scope needs an approved change before it is estimated or started. The piping lead and the project manager judge whether the base case is complete enough to approve.
Use the tool
Calculate now: Scope of Work
How this calculation works: Scope of Work
Related tools
- Piping Man-Hour Estimator puts labour hours on the deliverables this scope names.
- Piping Estimate Summary shows those hours as one view of the approved basis.
- Control Level Schedule places the same activities on the calendar.
- Physical Progress Calculator measures completion of the work this scope defined.
- Design Change Notice records work that was not in this approved scope.
- Historical Data Log keeps the finished job traceable to the scope it was estimated from.
