This is the third part of the five part series on how to write an effective User Requirement Specification. The topic of this part is ‘Scope’. If you missed the earlier two, see Considerations for Your User Requirement Specification and Process Overview for Your User Requirement Specification.
The remaining parts will be Control Philosophy and Hardware. As before, I would very much appreciate comments and input into this.
The points which I would like authors of User Requirement Specifications (URS) to consider are as follows:
- Describe the overall project scope. Consider hardware and software, consultancy services only, inclusion of instrumentation in the scope, support required for site installation, commissioning and start up. If you require an ongoing operational support, it is worth mentioning this in the URS as well.
- If this is an extension or replacement of an existing system, please provide details of the existing system. Old functional design specifications (FDS) documents are good, as are backups of the existing system. Loop diagrams help from a hardware point of view and photos can be invaluable.
- Break the scope down into packages if necessary. For example, safety instrumented systems (SIS), process control systems (PCS), fire & gas systems (F&G), Operator Training Systems (OTS), Energy Monitoring Systems. Consider describing the scope of each individually.
- Let the supplier know how much involvement the customer/end user will have in the project. For example, will documents be reviewed? Would the end user or customer like to attend design walkthrough meetings? Will you be involved in designing parts of the system? Remember to consider the impact of any projects which are being executed in parallel. At key points, these may affect the customer/end user ability to support the project.
- Indicate in what project phases you require the supplier to be involved. Front End Engineering Design (FEED)? Installation? Commissioning? Operator Training? If other phases (maybe based on plant availability) are required, please let the supplier know.
- Include a section which describes the documentation you require and what documentation you will produce. Do you require detailed design documents or just functional design documents? Are you expecting user manuals? Do you want the amount of documentation to be light? Is the project validated?
- What timescales and deadlines does the supplier need to adhere to? Is there any flexibility around these?
- It is important to describe what standards the project team and the finished system are required to comply/conform to. Please also ensure that you consider internal customer/end user standards. Additional effort may be required by the project team to meet them.
- List how much spareage (spare parts) is required to be included for and what types of spareage. For example, is it just installed spare, or are you also including design spare? Do you require additional licenses and I/O for a future planned project?
- Be clear about what is not included in scope. If you have provided piping and instrumentation diagram/drawings (P&IDs), is everything on the P&ID in scope or is some functionality provided by other systems? Are there any aspects which would often be in a system supplier’s scope, which in this case are not?
- Describe what serial packages are to be interfaced with as part of the project. Do you require testing at third-party locations? Where are these locations? Who is responsible for managing the serial packages and writing the mapping lists?
- Include an architecture diagram indicating to what systems the control system will link. Pay particular attention to systems which reside on a corporate network.
- Security is often a great concern therefore state the security requirements. Do they include a demilitarized zone (DMZ), locked-down USB ports or just passwords and electronic signatures?
- Explain the intentions around system installation. What type of shutdown will be required for installing the project? How long is it? Is a shutdown permitted?
Remember the clearer you are on scope, the fewer change requests you can expect to see later in the project. If there are items of scope which are unclear, state it in your URS. The proposal could include an indicative price to help with your budgeting if needed then. Even if it is not finalised at the point of quotation and tender vetting, it can still be included in the scope of work later through variation orders.
Please feel free to let me know your thoughts on the scoping of projects in the comments section below.
From Jim: You can also connect and interact with other project professionals in the Plan & Design group in the Emerson Exchange 365 community.
