By Jerry Lacatena
This might be a statement of the obvious to many, but it’s surprising how often some fundamental coordination tips for successful front-end engineering design and execution are forgotten under pressure. There can be exceptions and additions to any project; so, these tips are not all inclusive. This article hopes to provide a checklist for such work and why we need to remember.
Every front-end design project should at least start with a defined scope of work document detailing the extent and specifics of the work, expected deliverables, and format/content of the final product. This document is part of the contract, which ultimately controls the required work. It’s not uncommon for work scope to evolve during the course of a project, and often those involved just do what they are asked without consideration of contractual obligations or recording decisions which differ from those obligations. It is important not to lose sight of the formal project objectives, and to mutually change them as appropriate in a timely manner if they are no longer pertinent.
The contract may also indicate certain requirements for non-disclosure of proprietary information, which must be understood by the team and considered in the conduct of work. However in certain instances it should be confirmed that third parties, who need to provide information or respond to project requests, acknowledge confidentiality also.
It’s essential for the process designers to be aware of all performance requirements specified in any process guarantees, and if defined liabilities apply. The technical values and wording contained in the guarantee document are important, and surprisingly may not always convey the full expectations. If this occurs, it could result in litigation. For example, if a guarantee document includes a capacity, a product quality, and a catalyst life guarantee, the wording must clearly define that all guarantees are coincident during operations, and cannot be met independently and still satisfy the intent. All involved in execution want the facilities to perform, but generally guarantees without defined liabilities are considered of lesser priority than ones that do.
On any process unit, the type of unit, technology, and overall performance usually is detailed in a Basis of Design document. That document usually includes a simplified schematic of the process flow, the capacity, feed stocks with compositions, products with specifications, utility data, and battery limit conditions of process streams to/from unit interfaces. It’s advisable to check at the very beginning that the upstream and downstream unit’s design bases mesh, and on more complicated multi-unit projects, to prepare a systems diagram schematically depicting these interfaces and conditions. Ensuring that the design basis is current/valid and mutually understood by the parties involved (i.e., owner, licensor, contractor) is of paramount importance to a successful project.
Memoranda are often used to disseminate more specific process design criteria and owner preferences on the unit level, or they may apply to specific sections of a project. These would augment the basic engineering design data (BEDD) that every project should establish at the start of the project. BEDD includes climatic data, utility information, equipment standardization preferences, environmental regulations, and local codes which will apply to the project. These general design guidelines, instructions and information usually are assembled and distributed to the team and maintained for the duration of the project. These might also include safety margins on process equipment, operating flexibility requirements, or specific instructions (e.g., how to handle condensate recovery, preference for maximizing air cooling, or requested piping details that may deviate from general design standards due to location).
It is recommended that the use of design standards be identified quickly to avoid issues later. This is particularly important if the owner desires that his standards be used instead of the licensor’s or contractor’s, since there will likely be differences to reconcile.
An early task on larger projects also includes assessment of resources, capabilities, and schedule based on the latest execution plan and technical requirements on a per unit basis, and then assimilated into a master project schedule along with critical path analysis. Monthly performance will be tracked during the project to identify problems, and to forecast any course corrections necessary to achieve timely completion. Outside support by third-party consultants can be used to augment project teams with specific technical expertise, which tends to improve productivity and product quality. You can’t underestimate the value of having the right people in the right place on a project roster.
It helps greatly to establish a coordination procedure early to efficiently communicate between project team, client and/or others, and identify the key staff and client personnel (with contact information), who will receive correspondence distributions, and transmittals of specifications or information, and change notifications automatically. Electronic data and/or hardcopy procedures also need attention, and an e-file index set-up that covers project document control needs, so data can be properly filed, and recovered later when necessary.
It is prudent to conduct brief periodic status meetings (usually weekly or bi-weekly) to discuss schedule, priorities, outstanding information or decision needs, and current technical issues, changes, or problems. You can’t discount the value of face-to-face contact. Needs and action items are typically captured on a list with date and status tracked to confirm when items are resolved.
Proper management of change is required for efficient execution and technical quality. Project changes need to be defined, approved by a responsible party, and implemented by the team. Change impacts need to be assessed, and reflected into the master schedule and manpower requirements.
Quality and consistency of the unit deliverables with the design basis, guarantees, and scope should be assured via technical reviews prior to final release. HAZOP reviews may be conducted before (preferably) or after issue as long as the status is defined, and a plan agreed upon. All the approved comments must get incorporated prior to sign-off. If the project does not continue directly into the detail engineering phase, reviewed calculations and pertinent documents need to be organized and properly filed at completion.
The following checklist summarizes the main areas to be considered in Front-End Engineering Design.